Watchdog for Boser (HS-7001)
Hello, I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box. http://www.boser.com.tw/manual/HS-7001v1.1.pdf I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning. section .text global _start _start: I did assemble, link (ld) and got no error. But when I run, I got the following error: # ./watchdog.out Bus error (core dumped) I noticed that the port addresses used are similar with the following used by Super Micro Computer. I don't know if these are standards or not. I suspect that the boards are using same controller chips from Intel. I've been googling the web for more documentations on these but I could hardly find one. http://www.stinkfoot.org/wdt.txt How should I make this program works? Thanks, Won # dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: IntelR AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.21-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNTX-ID,b14 real memory = 528416768 (503 MB) avail memory = 507666432 (484 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: IntelR AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82845G (845G GMCH) SVGA controller mem 0xe000-0xe7ff,0xec70-0xec77 irq 16 at device 2.0 on pci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xe200-0xe21f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] 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 0xe000-0xe01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] 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 0xe100-0xe11f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] 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: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xec78-0xec7803ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: Intel 82801DB/L/M (ICH4) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib1 fxp0: Intel 82801DB (ICH4) Pro/100 Ethernet port 0xd100-0xd13f mem 0xec68-0xec680fff irq 20 at device 8.0 on pci1 miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:50:b7:f2:40:ea em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xd000-0xd03f mem 0xec62-0xec63,0xec60-0xec61 irq 18 at device 9.0 on pci1 em0: Ethernet address: 00:50:b7:f2:40:eb pci1: network at device 12.0 (no driver attached) pci1: network at device 13.0 (no driver attached) pcib2: PCI-PCI bridge at device 15.0 on pci1 pci2: PCI bus on pcib2 fxp1: Intel 82559 Pro/100 Ethernet port 0xc000-0xc03f mem 0xec502000-0xec502fff,0xec00-0xec0f irq 23 at device 0.0 on pci2 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:50:b7:f2:37:74 fxp2: Intel 82559 Pro/100 Ethernet port 0xc100-0xc13f mem 0xec50-0xec500fff,0xec10-0xec1f irq 20 at device 1.0 on pci2 miibus2: MII bus on fxp2 inphy2: i82555 10/100 media interface on miibus2 inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2: Ethernet address:
Re: keeping track of local modifications
Max, good day.
Mon, Dec 01, 2008 at 08:30:16AM +0100, Max Laier wrote:
On Monday 01 December 2008 07:07:00 [EMAIL PROTECTED] wrote:
* http://wiki.freebsd.org/LocalMercurial
This seems less of a resource hog, and (if I am understanding
matters correctly) is able to start from the installed /usr/src/...
rather than requiring the would-be hacker to download a redundant
instance, but I was concerned that the page may not be up to date
with current FreeBSD development methodology (e.g. csup vs cvsup).
If you want to contribute back, this is *not* the way to go. Patches from
anything other than SVN and maybe CVS are mostly useless.
May be I am missing something, but what's wrong with the patches from
other VCS, providing that with Subversion you can exchange only by the
plain diffs? Yes, Git/Mercurial patches should be applied with 'patch
-p1', but that's all. Subversion has no notion simular to 'git
format-patch' and 'git am', if I am not messing the things up, so the
only way to exchange with others are the patches themselves.
The local hg/git
approach is nice if you are already familiar with hg or git and just want to
keep some patch sets for yourself. If you are looking to keep/develop a patch
set and eventually share it with the world, svn or svk is the way to go.
The only issue I do see is about '$FreeBSD$', but plain Subversion
clients shouldn't mess with it. If person has commit privileges to the
FreeBSD repository, then yes, probably Subversion will be fine (but
there are git-svn and hgsvn, so locally user can work with the different
VCS even in this case).
Do I missing some important thing here?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSsbzOpdPqq.pgp
Description: PGP signature
Re: Watchdog for Boser (HS-7001)
Won De Erick schrieb: Hello, I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box. http://www.boser.com.tw/manual/HS-7001v1.1.pdf I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning. section .text global _start _start: I did assemble, link (ld) and got no error. But when I run, I got the following error: # ./watchdog.out Bus error (core dumped) MOV DX, 2EH MOV AL, 87H OUT DX, AL OUT DX, AL Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault. Regards Christoph ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote: Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault. Note that you can write to ports from userland by opening /dev/io - if you have it opened, you can write to the ports. -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
- Original Message From: Rink Springer [EMAIL PROTECTED] On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote: Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault. Note that you can write to ports from userland by opening /dev/io - if you have it opened, you can write to the ports. I've added the following at the end mov eax, 1 ; SYS_exit call doint doint: int 0x80 ret Besides, I can see the following at /dev crw--- 1 root wheel 0, 16 Nov 27 01:53 io How should I make this open? do i need to %include this? -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
On Mon, Dec 01, 2008 at 01:20:14AM -0800, Won De Erick wrote: Besides, I can see the following at /dev crw--- 1 root wheel 0, 16 Nov 27 01:53 io How should I make this open? do i need to %include this? No, you need to invoke an open syscall just in the same way you did the previous system call. Try looking at http://goodfellas.shellcode.com.ar/docz/asm/aslenguage.html, which is a tutorial for exactly this sort of thing. You don't have to read or write to it; just opening it is enough to get the I/O access you need. Regards, -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers 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: Watchdog for Boser (HS-7001)
Won De Erick schrieb:
- Original Message
From: Rink Springer [EMAIL PROTECTED]
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
Userland is not allowed to write to ports. That's the bus error you see.
Also without a call to the exit syscall at the end, it will segfault.
Note that you can write to ports from userland by opening /dev/io - if
you have it opened, you can write to the ports.
I've added the following at the end
mov eax, 1 ; SYS_exit
call doint
doint:
int 0x80
ret
Besides, I can see the following at /dev
crw--- 1 root wheel 0, 16 Nov 27 01:53 io
How should I make this open? do i need to %include this?
You're probably better of writing this in C. Here is a wrapper for the
out instruction:
static inline outb(unsigned short port, unsigned char data)
{
asm(outb %0, %1 : : a (data), dN (port));
}
As Rink mentioned, you have to open /dev/io. The process must have
super-user privileges, see io(4).
Regards
Christoph
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dd if=/dev/mem can hang a machine?
on 30/11/2008 22:14 Julian Stacey said the following: Gary Jennejohn wrote: On Fri, 28 Nov 2008 15:28:35 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: I have a new machine with DG33TL mainboard (ICH9/G33). In a course of some hacking I ran dd if=/dev/mem ... to scan all memory, this caused the machine to hang. I tried to reproduce and this is 100% reproducible. I am not used to such behavior. In older days I could scan all the memory without any issues. Could this be related to some modern form of memory-mapped IO? Or to Intel Management Engine (that seems t bite into DRAM)? Or something else? Just wondering. That's what I would assume. With some hardware just reading a register can be harmful. I just crashed 3 normally stable machines trying that. I only tried for casual interest. I acknowledge Gary's comment above :-) dd if=/dev/mem of=/dev/null FreeBSD lapa.js.berklix.net 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Fri Jul 7 17:56:30 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/compile/LAPA.small i386 FreeBSD laps.js.berklix.net 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Mon Sep 8 15:39:53 CEST 2008 [EMAIL PROTECTED]:/usr1/ftp/pri/FreeBSD/releases/7.0-RELEASE/src/sys/i386/compile/LAPS.small i386 FreeBSD john.js.berklix.net 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Sun Oct 12 20:59:28 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Thank you for going to all the trouble. I see now that I have to be more careful in this respect. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build kernel module spread on subdirectories?
On 1 Dec 2008, at 01:22 , Tim Kientzle wrote: .MAKEFILEDEPS: elements.mk .sinclude elements.mk .include bsd.kmod.mk ---8--- When I run make depend, it only includes SRCSs from BSDmakefile, not those from elements.mk. I would try adding a beforedepend requirement: beforedepend: elements.mk Look at /usr/share/mk/bsd.dep.mk, which has the 'make depend' logic. It supports optional beforedepend and afterdepend targets. Hi Tim, thanks for the tip. I've tried adding beforedepend: elements.mk rule before .sinclude. Unfortunately, everything is the same still. Is there a way to force explicitly what .MAKEFILEDEPS? beforedepend will create elements.mk, but that file won't be re-read and included before depend is called. Cheers, Nikola ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build kernel module spread on subdirectories?
On Monday 01 December 2008 12:08:13 Nikola Knežević wrote:
On 1 Dec 2008, at 01:22 , Tim Kientzle wrote:
.MAKEFILEDEPS: elements.mk
.sinclude elements.mk
.include bsd.kmod.mk
---8---
When I run make depend, it only includes SRCSs from BSDmakefile,
not those from elements.mk.
I would try adding a beforedepend requirement:
beforedepend: elements.mk
Look at /usr/share/mk/bsd.dep.mk, which has the 'make depend'
logic. It supports optional beforedepend and afterdepend
targets.
Hi Tim,
thanks for the tip.
I've tried adding beforedepend: elements.mk rule before .sinclude.
Unfortunately, everything is the same still. Is there a way to force
explicitly what .MAKEFILEDEPS? beforedepend will create elements.mk,
but that file won't be re-read and included before depend is called.
Does it have to be generated? What's the contents of that file after
generation and what generates it?
As you discovered, includes are done before targets. You would need seperate
invocations of make, to generate the file and get it included.
Maybe this will work, tho I doubt it (I expect the include to screw with the
beforedepend target):
beforedepend:
.if !exists(${.CURDIR}/elements.mk)
${MAKE} ${MAKEFLAGS} -f ${MAKEFILE} genmk
.endif
.if exists(${.CURDIR}/elements.mk)
.include ${.CURDIR}/elements.mk
.endif
genmk:
# do whatever here to generate the mk file
--
Mel
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: change to ee.c
Bruce Cran [EMAIL PROTECTED] writes: The version of ee in FreeBSD is fairly old: the latest from http://mahon.cwx.net/ is 1.4.6. Even so, the latest version still generates lots of warnings from gcc because the developer used NULL instead of '\0' (i.e the NULL constant instead of the NUL string). This is a good reason to define NULL as ((void *)0)... DES -- Dag-Erling Smørgrav - [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: change to ee.c
Eitan Adler [EMAIL PROTECTED] writes: Xin LI [EMAIL PROTECTED] writes: Tanks for interested in this but I'm afraid that your patch is incorrect. mkstemp returns a file descriptor rather than a string pointer, therefore, the subsequent open() would have undefined behavior. It looks like that we actually want fd = mkstemp() here. Thanks. If this is the case how come gcc did not return any warnings? Because ee(1) is built with most warnings disabled, precisely because the source code is of such poor quality (by modern standards). Try this: $ cd /usr/src/usr.bin/ee $ make clean $ make WARNS=3 21 | grep -cw warning 72 $ make WARNS=6 21 | grep -cw warning 188 This is on amd64; you will get fewer on i386. Someone added casts to silence legitimate warnings about pointers being assigned to integers, so gcc will only complain about those assignments on platforms where sizeof(int) == sizeof(void *). DES -- Dag-Erling Smørgrav - [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: Watchdog for Boser (HS-7001)
Christoph Mallon [EMAIL PROTECTED] writes: You're probably better of writing this in C. He's probably better off writing a watchdog(4) driver for the Boser (or getting someone to write one for him - not easy to do without hardware to test on, though) DES -- Dag-Erling Smørgrav - [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: Watchdog for Boser (HS-7001)
On Mon, 01 Dec 2008 09:38:51 +0100 Christoph Mallon [EMAIL PROTECTED] wrote: Won De Erick schrieb: Hello, I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box. http://www.boser.com.tw/manual/HS-7001v1.1.pdf I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning. section .text global _start _start: I did assemble, link (ld) and got no error. But when I run, I got the following error: # ./watchdog.out Bus error (core dumped) MOV DX, 2EH MOV AL, 87H OUT DX, AL OUT DX, AL Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault. See io(4), i386_get_ioperm(2), i386_set_ioperm(2), mem(4). --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: change to ee.c
Quoting Bruce Cran [EMAIL PROTECTED] (from Sun, 30 Nov 2008 10:31:56 -0800): On Sun, 30 Nov 2008 09:12:26 -0500 Eitan Adler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Cran wrote: snip The version of ee in FreeBSD is fairly old: the latest from http://mahon.cwx.net/ is 1.4.6. How difficult would it be to bring it up to date? How come it has not been updated so far? I'd guess it hasn't been updated because it works as it is and nobody has taken an interest in bringing it up to date. I don't know how many patches have been applied locally to it but that would be the main challenge in importing a newer version: you'd have to go through the FreeBSD CVS history and check that any changes/fixes that were made to FreeBSD's version are either already included in the new release or ensure that those changes get re-applied to the new version. It _may_ be more easy to find out which version is in our source tree, and make a diff between the original vendor version and what we have. Depending on the amount of changes there, this is faster than to real all the version control logs to determine if there's a difference or not. In the end you have to read some logs too, but only those, which change lines which a different from those of the vendor version (e.g. via the annotated view at cvsweb.freebsd.org). Bye, Alexander. -- In this vale Of toil and sin Your head grows bald But not your chin. -- Burma Shave http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
- Original Message
From: Christoph Mallon [EMAIL PROTECTED]
Won De Erick schrieb:
- Original Message
From: Rink Springer [EMAIL PROTECTED]
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
Userland is not allowed to write to ports. That's the bus error you see.
Also without a call to the exit syscall at the end, it will segfault.
Note that you can write to ports from userland by opening /dev/io - if
you have it opened, you can write to the ports.
I've added the following at the end
mov eax, 1 ; SYS_exit
call doint
doint:
int 0x80
ret
Besides, I can see the following at /dev
crw--- 1 root wheel 0, 16 Nov 27 01:53 io
How should I make this open? do i need to %include this?
You're probably better of writing this in C. Here is a wrapper for the out
instruction:
static inline outb(unsigned short port, unsigned char data)
{
asm(outb %0, %1 : : a (data), dN (port));
}
As Rink mentioned, you have to open /dev/io. The process must have super-user
privileges, see io(4).
will this be ok?
int fd = open(/dev/fido, O_RDWR);
Regards
Christoph
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
From: Won De Erick [EMAIL PROTECTED]
From: Christoph Mallon [EMAIL PROTECTED]
Won De Erick schrieb:
- Original Message
From: Rink Springer [EMAIL PROTECTED]
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
Userland is not allowed to write to ports. That's the bus error you see.
Also without a call to the exit syscall at the end, it will segfault.
Note that you can write to ports from userland by opening /dev/io - if
you have it opened, you can write to the ports.
I've added the following at the end
mov eax, 1 ; SYS_exit
call doint
doint:
int 0x80
ret
Besides, I can see the following at /dev
crw--- 1 root wheel 0, 16 Nov 27 01:53 io
How should I make this open? do i need to %include this?
You're probably better of writing this in C. Here is a wrapper for the out
instruction:
static inline outb(unsigned short port, unsigned char data)
{
asm(outb %0, %1 : : a (data), dN (port));
}
As Rink mentioned, you have to open /dev/io. The process must have super-user
privileges, see io(4).
will this be ok?
int fd = open(/dev/fido, O_RDWR);
aww.. i mean int sio = open(/dev/io, O_RDWR);
Regards
Christoph
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
- Original Message From: Dag-Erling Smørgrav [EMAIL PROTECTED] Christoph Mallon [EMAIL PROTECTED] writes: You're probably better of writing this in C. maybe i get this as an option. He's probably better off writing a watchdog(4) driver for the Boser (or getting someone to write one for him - not easy to do without hardware to test on, though) this is a great info. i am used to settings like the following when using ipmi-compliant platform. #bmc-watchdog -s -a 1 -i 100(#set timeout action to hard reset after a timeout of 100 seconds) then daemonize to constantly reset the timer, and prevent the box from restarting. I installed watchdog(/usr/ports/sysutils/watchdog) from ports, then noticed the following from the manual. watchdog [-d] [-t timeout] # watchdog -d -t 50 Timeout is 2^36 nanoseconds watchdog: patting the dog: Operation not supported but I don't know how it is linked with watchdogd(8). Little more explanation is appreciated, and/or an example. DES -- Dag-Erling Smørgrav - [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: Watchdog for Boser (HS-7001)
Won De Erick [EMAIL PROTECTED] writes: this is a great info. i am used to settings like the following when using ipmi-compliant platform. #bmc-watchdog -s -a 1 -i 100(#set timeout action to hard reset after a timeout of 100 seconds) then daemonize to constantly reset the timer, and prevent the box from restarting. I installed watchdog(/usr/ports/sysutils/watchdog) from ports, Firt of all, that port won't help you; it only supports the AMD Elan SoC. Second, we've had kernel support for the Elan watchdog longer than the port has existed. then noticed the following from the manual. watchdog [-d] [-t timeout] That's the base system watchdog(8); the port installs a watchdogd(8) that works *only* for Elan chips. There is a watchdogd(8) in the base system as well. # watchdog -d -t 50 Timeout is 2^36 nanoseconds watchdog: patting the dog: Operation not supported You need to load the appropriate watchdog driver first - and as far as I know, we don't have one for the Boser HS-7001. but I don't know how it is linked with watchdogd(8). Little more explanation is appreciated, and/or an example. man -k watchdog DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
TPM Device Driver - FreeBSD
Hello list, We are two undergraduate students studying computer engineering and informatics at Patra's University, Greece. We are currently working on our diploma thesis which is about developing a driver for the TPM (Trusted Platform Module) for FreeBSD.We think that TPM can enhance security in FreeBSD and could be a great addition to the TrustedBSD project. We are still in the begining of the project and since this is our first effort in implementing a device driver we are trying to gather and read all available documentation on the subject first. However, we were unable to find a source of information related to how the BSD kernel and device communication is implemented and we would greatly appreciate it if you could point us one; either in form of a book or an article/tutorial. Last but not least, we'd like to make clear that we are oppossed to any DRM-related use of this device, however we believe that the TPM can be used in security or cryptographic applications. Thanks in advance for your time. Best Regards, Marinos Ilias [EMAIL PROTECTED] Mellos Seraphim [EMAIL PROTECTED] -- echo Sysadmin know better bash than english. | sed s/min/mins/ \ | sed 's/better bash/bash better/' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TPM Device Driver - FreeBSD
On Mon, 2008-12-01 at 15:33 +0200, Ilias Marinos wrote: Hello list, We are two undergraduate students studying computer engineering and informatics at Patra's University, Greece. We are currently working on our diploma thesis which is about developing a driver for the TPM (Trusted Platform Module) for FreeBSD.We think that TPM can enhance security in FreeBSD and could be a great addition to the TrustedBSD project. We are still in the begining of the project and since this is our first effort in implementing a device driver we are trying to gather and read all available documentation on the subject first. However, we were unable to find a source of information related to how the BSD kernel and device communication is implemented and we would greatly appreciate it if you could point us one; either in form of a book or an article/tutorial. Last but not least, we'd like to make clear that we are oppossed to any DRM-related use of this device, however we believe that the TPM can be used in security or cryptographic applications. Thanks in advance for your time. Best Regards, Marinos Ilias [EMAIL PROTECTED] Mellos Seraphim [EMAIL PROTECTED] -- echo Sysadmin know better bash than english. | sed s/min/mins/ \ | sed 's/better bash/bash better/' This book[1] is very good, well worth a read. Not totally upto date, but reasonabley so. Cheers Tom [1] http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0201702452 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remapping kernel buffer in VMS of user process
On Mon, 1 Dec 2008 02:38:51 +0100 Alexej Sokolov [EMAIL PROTECTED] wrote: Hello, I would like to remap some buffers allocated in kernel space to memory space of certain process. The simplest way is to expose this buffer through device pager. Implement the driver callback and let userland to simply mmap the page. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Watchdog for Boser (HS-7001)
Dag-Erling Smørgrav [EMAIL PROTECTED] writes: You need to load the appropriate watchdog driver first - and as far as I know, we don't have one for the Boser HS-7001. I can't find the 7001 on Boser's web site, but their other SBCs seem to be ICH-based; try 'kldload ichwd'. DES -- Dag-Erling Smørgrav - [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: remapping kernel buffer in VMS of user process
On Mon, Dec 01, 2008 at 10:12:09AM -0500, Alexander Kabaev wrote: On Mon, 1 Dec 2008 02:38:51 +0100 Alexej Sokolov [EMAIL PROTECTED] wrote: Hello, I would like to remap some buffers allocated in kernel space to memory space of certain process. The simplest way is to expose this buffer through device pager. Implement the driver callback and let userland to simply mmap the page. Sorry, but I don't understand how to do it. I know how to implement mmap through character device. But I am working with network driver. Network devices doesn't appear in file system and they don't have any interface for mmaping. I think I can try to solve with task with: vm_map_lookup - to get a vm_object of allocated space and then vm_map_find (map_of_process, ... founded_object ...) - allocate a new space in the vms of process. I try to do it now with a small hope of success :-) -- Alexander Kabaev -- Alexej Sokolov [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: Hardware support for AMD Geode CS5536 audio?
Lionel, This is Andrew Gray. Thanx for testing. Does the command cat sound.raw /dev/dsp output the sound of my voice out of one of the speakers? Does it also give the bus master error message? Thanx Andrew Gray Lionel Flandrin wrote: On Wed, Nov 26, 2008 at 07:30:41PM -0800, ancelgray wrote: To AMD CS5536 users: This is Andrew Gray. I have finished the audio driver for the AMD CS5536 companion chip. It is working on a PC Engines Alix 1C low power board under FreeBSD 7.0. It can be found at: http://modelofreality.org/snd_amd5536.html Let me know how it goes. I own a fitpc[1] that runs an AMD Geode CPU with the AMD CS5536 chip. I followed the README (kldloaded the module, ran the two sysctl) and everything seemed to work fine: - As soon as I loaded the module I got (in the system messages): pcm0: AMD CS5536 port 0xd400-0xd47f irq 10 at device 15.3 on pci0 pcm0: [ITHREAD] pcm0: Wolfson WM9711/12 AC97 Codec - cat /dev/sndstat says: FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: AMD CS5536 at io 0xd400 irq 10 kld snd_cs5536 [MPSAFE] \ (2p:0v/1r:0v channels duplex default) However if I try to play something with mpg123 I get no sound and pcm0: bm0 bus master error every half second or so in the system messages. Please tell me if there's anything else I can provide to help you. [1] http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Cheers, -- Lionel Flandrin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Hardware-support-for-AMD-Geode-CS5536-audio--tp15002428p20774487.html Sent from the freebsd-hackers mailing list archive at Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin [EMAIL PROTECTED] wrote: May be I am missing something, but what's wrong with the patches from other VCS, providing that with Subversion you can exchange only by the plain diffs? Yes, Git/Mercurial patches should be applied with 'patch -p1', but that's all. Subversion has no notion simular to 'git format-patch' and 'git am', if I am not messing the things up, so the only way to exchange with others are the patches themselves. Conflicts... Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. I like Mercurial myself, but it's some times a pain to refresh patches that touch lines near $FreeBSD$. The only issue I do see is about '$FreeBSD$', but plain Subversion clients shouldn't mess with it. Bingo :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
Giorgos, good day.
Mon, Dec 01, 2008 at 07:21:03PM +0200, Giorgos Keramidas wrote:
On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin [EMAIL PROTECTED] wrote:
May be I am missing something, but what's wrong with the patches from
other VCS, providing that with Subversion you can exchange only by the
plain diffs? Yes, Git/Mercurial patches should be applied with 'patch
-p1', but that's all. Subversion has no notion simular to 'git
format-patch' and 'git am', if I am not messing the things up, so the
only way to exchange with others are the patches themselves.
Conflicts...
Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and
you may end up submitting patches that include unexpanded forms of the
$FreeBSD: $ text. These will fail to apply if they same patch
touches nearby lines.
Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help
in this case.
Thanks for clarification!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpO62QVqPGS4.pgp
Description: PGP signature
Re: keeping track of local modifications
On Mon, 1 Dec 2008 22:56:02 +0300, Eygene Ryabinkin [EMAIL PROTECTED] wrote: Giorgos, good day. Hi Eygene, thanks. The same to you too :) Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Thanks for clarification! Having said that, I have been using a patched version of the `crew' branch of Mercurial, for local FreeBSD work. I didn't want to convert the *full* history of the /head branch from Subversion, so I started by converting only the changes of 2008, using a local Subversion mirror for speed. The `convert' extension of Hg can pull changesets from Subversion, using the py-subversion bindings. An initial conversion of all the 2008 commits of the /head branch was bootstrapped with: % mkdir -p /hg/bsd % cd /hg/bsd % hg convert --config convert.svn.startrev='175021' \ --config convert.svn.trunk='head' \ --config convert.svn.branches='' \ --config convert.svn.tags='' \ file:///home/svn/base/ head After running for a while, this produced `/hg/bsd/head/.hg' which takes about 200 MB of space now, and it includes 6600+ changesets so far: % hg -R /hg/bsd/head tip changeset: 6603:bfec3e11214e branch: head tag: tip user:jasone date:Mon Dec 01 10:20:59 2008 + summary: Fix a lock order reversal bug that could cause deadlock during fork(2). % Rerunning the same command can incrementally pull only the new changes from Subversion, and it is fast enough that I saved it to a shell script called `/hg/bsd/pull-head.sh' and I run it from time to time, whenever I want to resync with 8.0-CURRENT: % pwd /hg/bsd % \time ./pull-head.sh scanning source... sorting... converting... 10 Adjustments to make a tags file a bit more suitable to amd64. 9 Fix fread() to return a correct value on platforms where sizeof(int) != 8 Catch up with the disappearance of sys/dev/hfa. 7 Trivial patch to show on which geom has the error been detected. 6 The times(3) function returns the number of CLK_TCKs since the 5 import ath hal 4 Switch to ath hal source code. Note this removes the ath_hal 3 Fix typo. 2 Add controller suspend/resume support. 1 Invoke _rtld_atfork_post earlier, before we reinitialize rtld locks 0 Add ixgbe(4) and upgt(4). 12.06 real 3.52 user 1.42 sys % It's nice to be able to use local-only operation for merging some of the patches I have to test, so it may be useful to anyone who wants to keep doing local FreeBSD work with Hg. In particular, it's nice to be able to look at the local diffs very very fast. Once the filesystem cache is warmed with the .hg/ contents of one workspace, I like being able to see stuff like: % \time hg diff -r bfec3e11214e:tip /dev/null 1.81 real 1.30 user 0.41 sys % I'll try to write to the Wiki how I keep a few local patches around, using a clone of the converted source tree. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
getting vm_object from allocated memory in kernel
Hello,
I try to allocate a memory in the system call and then I would like to get
vm_object
of allocated space to remap it later:
/* Syscall func */
static int
syscf(struct thread *td, void *sa)
{
...
vm_offset_t addr;
...
MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);
/* Then I try to get vm_obj */
vm_map_lookup(kernel_map, addr, VM_PROT_ALL,
myentry, myobject, mypindex, myprot, mywired);
/* OUT */
vm_map_lookup_done(kernel_map, myentry);
/* If i try to make system call it work successful but after a few seconds
happens
kernel panic */
...
}
could anyone give me a tip what I do wrong ?
# kgdb kernel.debug
vmcore.10
/home/alexandre/alexandre-da/misc/crash
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0589028
stack pointer = 0x28:0xe7a83758
frame pointer = 0x28:0xe7a83774
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 792 (zsh)
panic: from debugger
Uptime: 20m59s
Physical memory: 2034 MB
Dumping 73 MB: 58 42 26 10
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb)) bt
#0 doadump () at pcpu.h:195
#1 0xc0558c03 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0558e2c in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0457927 in db_panic (addr=Could not find the frame base for
db_panic.
) at /usr/src/sys/ddb/db_command.c:433
#4 0xc0458085 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401
#5 0xc0459ab5 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:222
#6 0xc057ed84 in kdb_trap (type=12, code=0, tf=0xe7a83718) at
/usr/src/sys/kern/subr_kdb.c:502
#7 0xc06b3edf in trap_fatal (frame=0xe7a83718, eva=20) at
/usr/src/sys/i386/i386/trap.c:890
#8 0xc06b489a in trap (frame=0xe7a83718) at
/usr/src/sys/i386/i386/trap.c:280
#9 0xc069dacb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0xc0589028 in propagate_priority (td=0xc5963210) at
/usr/src/sys/kern/subr_turnstile.c:272
#11 0xc05899a9 in turnstile_wait (ts=0xc5083870, owner=0xc5963210,
queue=Variable queue is not available.
) at /usr/src/sys/kern/subr_turnstile.c:739
#12 0xc054cdbd in _mtx_lock_sleep (m=0xc14540e8, tid=3312898576, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:416
#13 0xc054d141 in _mtx_lock_flags (m=0xc14540e8, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:186
#14 0xc066c234 in _vm_map_lock (map=0xc145408c, file=0x0, line=0) at
/usr/src/sys/vm/vm_map.c:449
#15 0xc0669e4a in kmem_malloc (map=0xc145408c, size=4096, flags=259) at
/usr/src/sys/vm/vm_kern.c:296
#16 0xc0660a77 in page_alloc (zone=0xc1445780, bytes=4096, pflag=0xe7a8388f
\002\200\207D�\003, wait=259) at /usr/src/sys/vm/uma_core.c:955
#17 0xc065fb3c in slab_zalloc (zone=0xc1445780, wait=259) at
/usr/src/sys/vm/uma_core.c:820
#18 0xc0660014 in uma_zone_slab (zone=0xc1445780, flags=3) at
/usr/src/sys/vm/uma_core.c:2010
#19 0xc0663286 in uma_zalloc_arg (zone=0xc1445780, udata=0x0, flags=3) at
/usr/src/sys/vm/uma_core.c:2111
#20 0xc05bf62f in cache_enter (dvp=0xc5724770, vp=0x0, cnp=0xe7a83bd0) at
uma.h:277
#21 0xc06521d8 in ufs_lookup (ap=0xe7a83a00) at
/usr/src/sys/ufs/ufs/ufs_lookup.c:446
#22 0xc06c9ee2 in VOP_CACHEDLOOKUP_APV (vop=0xc073a180, a=0xe7a83a00) at
vnode_if.c:153
#23 0xc05bffa0 in vfs_cache_lookup (ap=0xe7a83a84) at vnode_if.h:83
#24 0xc06cbb26 in VOP_LOOKUP_APV (vop=0xc073a6a0, a=0xe7a83a84) at
vnode_if.c:99
#25 0xc05c64c1 in lookup (ndp=0xe7a83ba8) at vnode_if.h:57
#26 0xc05c7118 in namei (ndp=0xe7a83ba8) at
/usr/src/sys/kern/vfs_lookup.c:219
#27 0xc05d4b5d in kern_stat (td=0xc576d210, path=0xbfbe5238 Address
0xbfbe5238 out of bounds, pathseg=UIO_USERSPACE, sbp=0xe7a83c18)
at /usr/src/sys/kern/vfs_syscalls.c:2109
#28 0xc05d4d0f in stat (td=0xc576d210, uap=0xe7a83cfc) at
/usr/src/sys/kern/vfs_syscalls.c:2093
#29 0xc06b44b7 in syscall (frame=0xe7a83d38) at
/usr/src/sys/i386/i386/trap.c:1035
#30 0xc069db30 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:196
#31 0x0033 in ?? ()
Previous
Re: change to ee.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Leidinger wrote: It _may_ be more easy to find out which version is in our source tree, and make a diff between the original vendor version and what we have. Depending on the amount of changes there, this is faster than to real all the version control logs to determine if there's a difference or not. In the end you have to read some logs too, but only those, which change lines which a different from those of the vendor version (e.g. via the annotated view at cvsweb.freebsd.org). I think I'm going to work on diff from current vendor release to ours and see what happens. - -- Eitan Adler GNU Key fingerptrint: 2E13 BC16 5F54 0FBD 62ED 42B6 B65F 24AB E9C2 CCD1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk0jP8ACgkQtl8kq+nCzNHFvgCfcs7/au6FohllKbVTmMHjttn1 178Aniek69WKfyOHyh7woO9sDeBwNLMU =ds5J -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build kernel module spread on subdirectories?
As you discovered, includes are done before targets. You would need seperate invocations of make, to generate the file and get it included. heresy Provided the module in question is contemplated for delivery as a port, rather than as part of the base -- so that having a build dependency on a port is tolerable -- perhaps it would be more easily built using devel/gmake? /heresy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Not sure I understand what is meant by unexpanded here, since it looks as if this sed example would convert an expanded form -- containing the version info -- to an unexpanded one that merely shows where that info should go. Perhaps it's my ClearCase background showing through, but I'd think it highly desirable for a patch to include what I think of as the expanded tag line -- including the version info, as it appears in the distributed files under /usr/src -- thereby explicitly showing the version on which the patch is based (the base contributor in ClearCase-speak). This should greatly simplify merging in the (likely) event that other development has occurred on the same file in the meantime -- provided one is using a 3-way merge tool that understands such things. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware support for AMD Geode CS5536 audio?
Lionel replies: Hi Andrew, thank you for your quick reply. cat count.raw /dev/dsp does indeed work without any message in the syslog. If I try to cat /dev/urandom /dev/dsp I get a very thin white-ish noise and still no message. (I set all levels to 100 with mixer(8)) This is rather encouraging, I hope it helps. By the way, I forgot to put the version I'm running in my last email: # uname -a FreeBSD home.svkt.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Sat \ Nov 1 23:24:38 CET 2008 \ [EMAIL PROTECTED]:/home/simias/build-fitpc/obj/i386/usr/src/sys/FITPC-CONF \ i386 Tell me if I can try something else or if you want me to provide you more details about my system. I'm using a heavily trimmed down kernel configuration so maybe I inadvertently disabled something mpg123 needs. Lionell, OK, this is indeed encouraging. Perhaps my default block size of 256 bytes is too small for the 44 Khz audio. I did not test the driver with mpg123. I am using Linphone with just mono 8 Khz audio. The 256 byte block size works fine for me. I will install the mpg123 package soon and see what's up. Thanx again for testing. Andrew Gray -- View this message in context: http://www.nabble.com/Hardware-support-for-AMD-Geode-CS5536-audio--tp15002428p20786956.html Sent from the freebsd-hackers mailing list archive at Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
Perry, good day.
Mon, Dec 01, 2008 at 09:08:25PM -0800, [EMAIL PROTECTED] wrote:
Git and Mercurial cannot import Subversion $FreeBSD$ lines
so far, and you may end up submitting patches that include
unexpanded forms of the $FreeBSD: $ text. These will
fail to apply if they same patch touches nearby lines.
Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help
in this case.
Not sure I understand what is meant by unexpanded here, since
it looks as if this sed example would convert an expanded form
-- containing the version info -- to an unexpanded one that
merely shows where that info should go.
If you'll look at the diffs that are provided by Subversion, you'll
see that '$Id$' tags at the diff are shrinked to the '$Id' if keyword
expansion is enabled. For example,
-
Index: ChangeLog
===
--- ChangeLog (revision 40)
+++ ChangeLog (working copy)
@@ -1,4 +1,5 @@
$Id$
+add
Current version:
- Added CRL check for all certificates in chain during S/MIME
-
while original ChangeLog reads
-
$Id: ChangeLog 35 2008-04-11 10:02:37Z root $
add
Current version:
- Added CRL check for all certificates in chain during S/MIME
verification.
-
The above sed command will normalize $FreeBSD$ tags (de-expand them,
you're right that the wording was a bit ambigious).
But I was out of coffee yesterday, so I missed an important thing: such
diffs won't also apply, because you're really right: Subversion shrinks
'Id' (think 'FreeBSD') tags for diffs it is generating, but it has no
command 'svn patch' that will shrink these tags, apply the diff and
unshink them to the original form. And this matters when you're
generating the diff against version N, but maintainer applies it to the
version N + m. If I am correct, there is no simple automatic solution,
but special patching as described above will be needed.
Please, correct me if I am wrong.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpQpFu57wp8K.pgp
Description: PGP signature
