Re: Fscking a partition mounted Read only...
Rick C. Petty wrote: > VANHULLEBUS Yvan wrote: > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > > under FreeBSD6 and do the test again on FreeBSD 6 ? > > I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if > any GEOM-related stuff ever made it into fsck, but certainly the background > checking code and softupdates changes were introduced about that time. Does 4.x fsck even support UFS2? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Threading system calls (int 80h)
On Mon, Oct 16, 2006 at 02:08:59PM +0200, Marco van de Voort wrote: > > > > On Sunday 15 October 2006 01:32, David Xu wrote: > > > You are going to be unable to use libc if you create raw thread in your > > > program, libc uses pthread APIs, if you create a raw thread, your > > > program will crash if you use any libc function which needs pthread > > > interface. > > > > I don't want to link to libc. So, how do I create a raw thread? > > (digging deep into memory) > > Have a look how the linuxator emulates the clone() syscall with (IIRC) > rfork. A limited route, but iirc it works. linuxolator clone() uses fork1() which is unaccessible from outside kernel. there is a "user space implementation" of clone() in linuxthreads which uses rfork() but rfork creates "normal processes". but you can pass flags to rfork() thus emulation most of the needs of threads (shared memory etc.) roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Threading system calls (int 80h)
On Tuesday 17 October 2006 16:10, Divacky Roman wrote: > On Mon, Oct 16, 2006 at 02:08:59PM +0200, Marco van de Voort wrote: > > > On Sunday 15 October 2006 01:32, David Xu wrote: > > > > You are going to be unable to use libc if you create raw thread in > > > > your program, libc uses pthread APIs, if you create a raw thread, > > > > your program will crash if you use any libc function which needs > > > > pthread interface. > > > > > > I don't want to link to libc. So, how do I create a raw thread? > > > > (digging deep into memory) > > > > Have a look how the linuxator emulates the clone() syscall with (IIRC) > > rfork. A limited route, but iirc it works. > > linuxolator clone() uses fork1() which is unaccessible from outside kernel. > there is a "user space implementation" of clone() in linuxthreads which > uses rfork() but rfork creates "normal processes". but you can pass flags > to rfork() thus emulation most of the needs of threads (shared memory etc.) > > roman You can use rfork() to create kernel threads, but you won't have POSIX signal and job control support in kernel, this is also one of important threading work in the past. Also rfork() does not allow you to specify user stack, you have to add some tricky code to make it safe before new thread really can do real work, plus if you want TLS to work, you have to do more work, this is why we invent THR syscalls to do all the initializing work in a single syscall, there are other problems of rfork I can not think of at the moment. David Xu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
delete 2 macros from queue.h
Hello, I made the Russian translation of queue(3) and found out that in sys/sys/queue.h there are macros SLIST_FOREACH_PREVPTR and STAILQ_REMOVE_HEAD_UNTIL which are not described in queue(3). The macros SLIST_FOREACH_PREVPTR is used only in sys/kern/sysv_sem.c and the macros STAILQ_REMOVE_HEAD_UNTIL is used only in sys/dev/ubsec/ubsec.c . Thus, I think that these macros must be described in queue(3) or be deleted. I made the patch for removing such macros from sys/sys/queue.h . The patch can be fetched from http://www.rosmir.org/freebsd/patches/patch-queue . Please, test it and fix it. Stepan Baranov. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fscking a partition mounted Read only...
On Tue, Oct 17, 2006 at 10:06:36AM +0200, Oliver Fromme wrote: > Rick C. Petty wrote: > > I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if > > any GEOM-related stuff ever made it into fsck, but certainly the background > > checking code and softupdates changes were introduced about that time. > > Does 4.x fsck even support UFS2? No it does not, so that would be a problem as well =) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: LSI1064 and LSI1064E and mpt
Hi Matthew. I gave up on the PCI-express version of the card for the time being. The PCI-X running the same firmware works fine, except for the slow RAID of course. I still have the main problem I try to get to the bottom off, and that is that the RAID-1 volume da0 is very slow. - Slow with even just 1 disk. - Slow when sync completed or not. Without RAID configured , and having 2 disks mounted, the disks are fast ~ 30 Mbytes/sec The disks are Fujitsu SATA laptop drives. I was poking around the MPI libraries of Linux, and I see they have some extra entries related to SAS. Also the file mptsas.c in Linux sets up the link speed and so on on the PHY. Do not know if something there is needed yet. Any idea of where I can start looking for the problem ? - link speed - dma - caching - etc ..etc .. P.S. A way earlier version of the MPI , somewhere in 2005, behaves the same as far as the RAID speed is concerned. Johan -Original Message- From: ext Matthew Jacob [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 7:17 PM To: Kruger Johannes (Nokia-ES/Boston) Cc: [EMAIL PROTECTED]; freebsd-hackers@freebsd.org Subject: Re: LSI1064 and LSI1064E and mpt And the problem is? On 10/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi. > I figured I'll give this mailing list a shot in helping me figure out a > problem I have. > > I have 2 reference boards from LSI, using the mpt driver. > Each one has MPI FW revision 1.5.13.0 > They repond differently. > The PCI-X version LSI1064 reports running in RAID-1 and do NOT get the > error message. > The PCI-express do get the error message, and thus reports RAID-0 > Both are configured as RAID-1 Integrated mirroring. Using the same 2 > disks on both, swapping them out back and forth between the testing. > > NOTE: the behavior is the same with FW version 1.5.12.0 except with > 1.5.12.0 I get notify events on which I can report sync percentage. > > ERROR MESSAGE --- > . > . > mpt_read_cfg_page: Config Info Status 22 > mpt_refresh_raid_vol: Failed to read RAID Vol Page(0) > mpt0:vol0(mpt0:0:0): Settings (netlog:mpt .. ) > mpt0:vol0(mpt0:0:0): 0 Members: > mpt0:vol0(mpt0:0:0): RAID-0 - Optimal > . > . > -- > > > Johan > > > . > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
Dinesh et al: Did this problem ever get resolved? I'm tracking down a very similar bug with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. Dinish: What platform are you using? You said you had a 4x re(4) SBC, but never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network appliance. URL below. My platform is netbsd-3, but I just tried -current to see if recent rtl8169.c changes fix it. No dice. No dice with NetBSD -current either. FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 probes then fails the diagnostic function, then detatches. re1, re2, re3 all then sucsessfully probe on my system, but then they show no media status and tcpdump(8)/arp(8) show no activity. They're dead in the water. There has also been some mention of the errors below on NetBSD and OpenBSD probably because of the bitrot/driver drift: http://marc.theaimsgroup.com/?t=11165804011&r=1&w=2 http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a go. I see a 8139C+ fix was commited 5 weeks ago by [EMAIL PROTECTED] Based on some other threads I've been reading on "8139C+ Watchdog Timeouts" and "Diag failed, failing to attach" related messages, I imagine FreeBSD has this covered. re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX re0: interrupting at irq 5 re0: Ethernet address 00:60:e0:e1:3e:31 re0: using 64 tx descriptors ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x00, model 0x, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re: diagnostic failed, failed to receive packet in loopback mode re0: attach aborted due to hardware diag failure ukphy0 detached - Full dmesg(8): NetBSD 3.1_RC3 (CFRDMDROOT.MPACPI-$Revision: 1.21.4.5 $) #9: Sat Oct 14 21:19:14 EDT 2006 [EMAIL PROTECTED]:/home/nbsd/obj.i386/temp/sys/arch/i386/compile/CFRDMDROOT.MPACPI total memory = 189 MB avail memory = 166 MB BIOS32 rev. 0 found at 0xfb570 mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: VIA C3 Samuel 2/Ezra (686-class), 800.11 MHz, id 0x673 cpu0: features 80803035 cpu0: features 80803035 cpu0: features 80803035<3DNOW> cpu0: "VIA Samuel 2" cpu0: I-cache 64 KB 32B/line 4-way, D-cache 64 KB 32B/line 4-way cpu0: L2 cache 64 KB 32B/line 4-way cpu0: ITLB 128 4 KB entries 8-way cpu0: DTLB 128 4 KB entries 8-way cpu0: 4 page colors acpi0 at mainbus0 acpi0: using Intel ACPI CA subsystem version 20040211 acpi0: X/RSDT: OemId , AslId acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present ACPI Object Type 'Processor' (0x0c) at acpi0 not configured acpibut0 at acpi0 (PNP0C0C): ACPI Power Button PNP0C01 [System Board] at acpi0 not configured PNP0A03 [PCI Bus] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured PNP [AT Interrupt Controller] at acpi0 not configured PNP0200 [AT DMA Controller] at acpi0 not configured PNP0100 [AT Timer] at acpi0 not configured PNP0B00 [AT Real-Time Clock] at acpi0 not configured PNP0800 [AT-style speaker sound] at acpi0 not configured npx1 at acpi0 (PNP0C04) npx1: io 0xf0-0xff irq 13 npx1: using exception 16 fdc0 at acpi0 (PNP0700) fdc0: io 0x3f0-0x3f5,0x3f7 irq 6 drq 2 com0 at acpi0 (PNP0501-1) com0: io 0x3f8-0x3ff irq 4 com0: ns16550a, working fifo com1 at acpi0 (PNP0501-2) com1: io 0x2f8-0x2ff irq 3 com1: ns16550a, working fifo lpt0 at acpi0 (PNP0400-1) lpt0: io 0x378-0x37f irq 7 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: VIA Technologies product 0x0601 (rev. 0x05) agp0 at pchb0: aperture at 0xe800, size 0x1000 ppb0 at pci0 dev 1 function 0: VIA Technologies product 0x8601 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 0 function 0: Trident Microsystems product 0x8500 (rev. 0x6a) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) wsmux1: connecting to wsdisplay0 pcib0 at pci0 dev 7 function 0 pcib0: VIA Technologies VT82C686A PCI-ISA Bridge (rev. 0x40) viaide0 at pci0 dev 7 function 1 viaide0: VIA Technologies VT82C686A (Apollo KX133) ATA100 controller viaide0: bus-master DMA support present viaide0: primary channel configured to compatibility mode viaide0: primary channel interrupting at irq 14 atabus0 at viaide0 channel 0 viaide0: secondary channel configured to compatibility mode viaide0: secondary channel interrupting at irq 15 atabus1 at viaide0 channel 1 uhci0 at pci0 dev 7 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x1a) uhci0: interrupting at irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA Technolog
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: > > Dinesh et al: > > Did this problem ever get resolved? I'm tracking down a very similar bug > with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. > > Dinish: What platform are you using? You said you had a 4x re(4) SBC, but > never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network > appliance. URL below. My platform is netbsd-3, but I just tried -current > to see if recent rtl8169.c changes fix it. No dice. > > No dice with NetBSD -current either. > > FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 > probes then fails the diagnostic function, then detatches. re1, re2, > re3 all then sucsessfully probe on my system, but then they show no > media status and tcpdump(8)/arp(8) show no activity. They're dead in > the water. > > There has also been some mention of the errors below on NetBSD and OpenBSD > probably because of the bitrot/driver drift: > > http://marc.theaimsgroup.com/?t=11165804011&r=1&w=2 > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 > > I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a > go. I see a 8139C+ fix was commited 5 weeks ago by [EMAIL PROTECTED] Based > on > some other threads I've been reading on "8139C+ Watchdog Timeouts" and > "Diag failed, failing to attach" related messages, I imagine FreeBSD has > this covered. > > re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX > re0: interrupting at irq 5 > re0: Ethernet address 00:60:e0:e1:3e:31 > re0: using 64 tx descriptors > ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface > ukphy0: OUI 0x00, model 0x, rev. 0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re: diagnostic failed, failed to receive packet in loopback mode > re0: attach aborted due to hardware diag failure > ukphy0 detached > Long ago re_diag() code was disabled by default(rev 1.68). So I think you should never see the "diagnostic failed" message on FreeBSD. The other odd thing I see from your demsg output is ukphy(4) attachment. If you boot system with bootverbose mode ukphy(4) would have printed PHY OID and model number. Please let me know the OID/model number. I guess it should use rlphy(4). (If you should use NetBSD you may need to define MIIVERBOSE to active verbose message.) -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Wed, Oct 18, 2006 at 10:55:11AM +0900, To Brian A. Seklecki wrote: > On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: > > > > Dinesh et al: > > > > Did this problem ever get resolved? I'm tracking down a very similar bug > > with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. > > > > Dinish: What platform are you using? You said you had a 4x re(4) SBC, > but > > never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM > network > > appliance. URL below. My platform is netbsd-3, but I just tried > -current > > to see if recent rtl8169.c changes fix it. No dice. > > > > No dice with NetBSD -current either. > > > > FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 > > probes then fails the diagnostic function, then detatches. re1, re2, > > re3 all then sucsessfully probe on my system, but then they show no > > media status and tcpdump(8)/arp(8) show no activity. They're dead in > > the water. > > > > There has also been some mention of the errors below on NetBSD and > OpenBSD > > probably because of the bitrot/driver drift: > > > > http://marc.theaimsgroup.com/?t=11165804011&r=1&w=2 > > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 > > > > I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a > > go. I see a 8139C+ fix was commited 5 weeks ago by [EMAIL PROTECTED] > Based on > > some other threads I've been reading on "8139C+ Watchdog Timeouts" and > > "Diag failed, failing to attach" related messages, I imagine FreeBSD has > > this covered. > > > > re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX > > re0: interrupting at irq 5 > > re0: Ethernet address 00:60:e0:e1:3e:31 > > re0: using 64 tx descriptors > > ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface > > ukphy0: OUI 0x00, model 0x, rev. 0 ^^ Oops, I've missed OID/model number showed on your message. Sorry. Since ukphy(4) showed bogus model number I have no idea what PHY hardware the NIC has. Would you show me "pciconf -lv" output? > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re: diagnostic failed, failed to receive packet in loopback mode > > re0: attach aborted due to hardware diag failure > > ukphy0 detached > > > > Long ago re_diag() code was disabled by default(rev 1.68). So I think > you should never see the "diagnostic failed" message on FreeBSD. > The other odd thing I see from your demsg output is ukphy(4) > attachment. If you boot system with bootverbose mode ukphy(4) would > have printed PHY OID and model number. Please let me know the > OID/model number. I guess it should use rlphy(4). > (If you should use NetBSD you may need to define MIIVERBOSE to active > verbose message.) -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
