Re: Size of SD devices supported?
On Thu, Jan 08, 2009 at 10:58:52AM +1100, Jonathan Gray wrote:
On Wed, Jan 07, 2009 at 02:49:50PM -0500, STeve Andre' wrote:
My new Thinkpad W500 has a SD slot, and stuffing a 1G card in
works just fine.
I borrowed a 16G SD card, and that gives a can't enable card
error.
I just found specs for the SD card, and wonder if the current
code works with cards beyond 4G? Or, do I have a defective 16G
card? (I currently have no way to test that). I haven't seen much
in the way of discussion about this.
This diff should let you use SDHC cards (most cards = 4GB).
Let me know how it goes.
Last one didn't have the change needed for block writes, try this:
Index: sdmmc.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving revision 1.16
diff -u -p -r1.16 sdmmc.c
--- sdmmc.c 2 Dec 2008 23:49:54 - 1.16
+++ sdmmc.c 8 Jan 2009 12:05:53 -
@@ -569,6 +569,32 @@ sdmmc_go_idle_state(struct sdmmc_softc *
}
/*
+ * Send the SEND_IF_COND command, to check operating condition
+ */
+int
+sdmmc_send_if_cond(struct sdmmc_softc *sc, uint32_t card_ocr)
+{
+ struct sdmmc_command cmd;
+ uint8_t pat = 0x23;
+ uint8_t res;
+
+ bzero(cmd, sizeof cmd);
+
+ cmd.c_opcode = SD_SEND_IF_COND;
+ cmd.c_arg = ((card_ocr SD_OCR_VOL_MASK) != 0) 8 | pat;
+ cmd.c_flags = SCF_CMD_BCR | SCF_RSP_R7;
+
+ if (sdmmc_mmc_command(sc, cmd) != 0)
+ return 1;
+
+ res = cmd.c_resp[0];
+ if (res != pat)
+ return 1;
+ else
+ return 0;
+}
+
+/*
* Retrieve (SD) or set (MMC) the relative card address (RCA).
*/
int
Index: sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.9
diff -u -p -r1.9 sdmmc_mem.c
--- sdmmc_mem.c 2 Dec 2008 23:49:54 - 1.9
+++ sdmmc_mem.c 8 Jan 2009 12:05:53 -
@@ -93,6 +93,9 @@ sdmmc_mem_enable(struct sdmmc_softc *sc)
/* Tell the card(s) to enter the idle state (again). */
sdmmc_go_idle_state(sc);
+ if (sdmmc_send_if_cond(sc, card_ocr) == 0)
+ host_ocr |= SD_OCR_SDHC_CAP;
+
/* Send the new OCR value until all cards are ready. */
if (sdmmc_mem_send_op_cond(sc, host_ocr, NULL) != 0) {
DPRINTF((%s: can't send memory OCR\n, SDMMCDEVNAME(sc)));
@@ -224,14 +227,23 @@ sdmmc_decode_csd(struct sdmmc_softc *sc,
* specification version 1.0 - 1.10. (SanDisk, 3.5.3)
*/
csd-csdver = SD_CSD_CSDVER(resp);
- if (csd-csdver != SD_CSD_CSDVER_1_0) {
+ switch (csd-csdver) {
+ case SD_CSD_CSDVER_2_0:
+ sc-sc_flags |= SMF_SDHC;
+ csd-capacity = SD_CSD_V2_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_V2_BL_LEN;
+ break;
+ case SD_CSD_CSDVER_1_0:
+ csd-capacity = SD_CSD_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
+ break;
+ default:
printf(%s: unknown SD CSD structure version 0x%x\n,
SDMMCDEVNAME(sc), csd-csdver);
return 1;
+ break;
}
- csd-capacity = SD_CSD_CAPACITY(resp);
- csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
} else {
csd-csdver = MMC_CSD_CSDVER(resp);
if (csd-csdver != MMC_CSD_CSDVER_1_0
@@ -403,7 +415,10 @@ sdmmc_mem_read_block(struct sdmmc_functi
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_READ_BLOCK_MULTIPLE : MMC_READ_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sc-sc_flags SMF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_CMD_READ | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
@@ -458,7 +473,10 @@ sdmmc_mem_write_block(struct sdmmc_funct
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_WRITE_BLOCK_MULTIPLE : MMC_WRITE_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sc-sc_flags SMF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
Index: sdmmcreg.h
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmcreg.h,v
retrieving revision 1.3
diff -u -p -r1.3 sdmmcreg.h
--- sdmmcreg.h 18 Mar 2007 22:21:21 - 1.3
+++ sdmmcreg.h 8 Jan 2009 12:05:54 -
@@ -38,6 +38,7 @@
/* SD commands */ /* response type */
Re: pppd, ip-up script and privileges
On 2009-01-08, patrick keshishian pkesh...@gmail.com wrote: I don't know how to use git, nor am I finding their web-interface very intuitive, but from the link you provided, looking at the diff for main.c, upstream never had setuid(geteuid()) as far as I can see: /* Leave the current location */ - (void) setsid();/* No controlling tty. */ + (void) setsid();/* No controlling tty. */ (void) umask (S_IRWXG|S_IRWXO); - (void) chdir (/); /* no current directory. */ + (void) chdir (/); /* no current directory. */ + setuid(0); /* set real UID = root */ setgid(getegid()); They only added the setuid(0). They removed setuid(geteuid()) in the preceding commit, http://git.ozlabs.org/?p=ppp.git;a=commitdiff;h=8a68ed35b0312fe46436a3490097a4fd c5af1c95 setuid(geteuid()) is equivalent to setuid(0) since set-user-ID pppd will have effective uid of 0 (file owner is root). Hmmm. I wrote a test program to display geteuid() and made it setuid root, which only displayed the unprivileged uid, which is what I based my interpretation on. But now I realise /tmp was a bad choice of a location to run this since it's mounted nosuid... ;-) Ok, I agree with this now then.
Re: nc/tar pipeline speed issue throught lo0 interface
New founds about this: If from the sending side you send an already tared file wich contains itself .tar.gz files, this slowness also happends: to reproduce: - tar a file or a tree wich contains tar.gz files. # cat newfile.tar | nc localhost 222 understanding the other edge have nc -l 222 -Jesus. Jesus Sanchez escribis: Hi there, using 4.4 stable. I've found (I think) a weird behaviour on combining nc and tar in a pipeline through lo0 interface that causes very slow speeds when sending .tar.gz and some .pdf files. Warning: this issue it's not really important and only happends under very specific circunstances and don't have any relevant use under productive environments, this behaviour was found coding some scripts and using lo0 interface to test them. How to reproduce it (under any version of OpenBSD): - download (for example) the sys.tar.gz file from a mirror. - do from a console with root privileges: # cd /tmp # nc -l 222 | tar xvf - - do from the dir with the sys.tar.gz file # tar cvf - sys.tar.gz | nc 127.0.0.1 222 At this point what's happening it's a pipeline with nc listening on port 222 and untaring what it recieves. At the other side, nc it's sending a tar file wich contains the file sys.tar.gz (that's why I mentioned this doesn't make sense and don't have any productive use, cause sys.tar.gz it's already tared and gziped) all this stuff thought lo0 interface. The issue here it's what the speed through lo0 interface when sending tar.gz files it's very slow, I experienced a 150 KB/s rate, when the normal thing it's about 10 MB/s or more. Some aclarations: - If you change the receving line for: # nc -l 222 file.tar this issue doesn't happends, and you get the right speed (10 MB/s or more) - This only happends with the specifically combination of the tar x at the recieving end and the sending files contain tar.gz files (also happends with some pdf files but don't know why). - This only happends if it's through the lo0 interface. I don't have skills to determine the cause, I just thought this isn't normal, but as said, it's a really weird issue and not really productive. I didn't included dmesg cause it happends on various machines regardless the OpenBSD version. should write a sendbug?? Thanks for all! -Jesus
mutt 1.5.18 and set trash directive in .muttrc
Hello all, i am using mutt 1.5.18 to handle my mail. I set it up via my muttrc file so that when i delete a mail, it goes to a Trash Folder. This is defined in .muttrc like this set trash=$HOME/.mail/mlists.pg-sec.com/Trash/ Now id like to move my mail and setup to a OpenBSD 4.4 Machine, i installed Mutt 1.5.18 and everything works fine, except that mutt under OpenBSD doesn't seem to recognize the set trash directive in my .muttrc; instead upon starting mutt, mutt complains that: Error in /home/mlists/.mutt/muttrc, line 8: trash: unknown variable source: errors in /home/mlists/.mutt/muttrc This is strange, because set trash should be working without any patches or the like as far as i know. Can anyone help me to troubleshoot this? Thanks a lot, David
Re: Openbsd mounting
Hi! On Sat, Dec 20, 2008 at 09:14:39PM +, Dorian B|ttner wrote: rizzo0917 schrieb: and usb devices. keyword is hotplugd(8), includes example. And what does happen if someone uses the example and then unplugs that device? Then one has a mount with the block device used for it vanished. Even if I mount things manually and even if I forget to unmount it just once (e.g. an USB stick or an USB harddisk), my system is hosed. Not even a forced unmount works any more (at least last time I did that). Had to shutdown now, umount everything else so I had less unclean filesystems (remount the root fs readonly) and then reboot. amd, OTOH, would unmount the fs soon after it isn't used any more (which can be lucky enough to be before it's unplugged). And on trying to use it it would try to mount it which would either succeed (if it's plugged) or not (if it's not (yet) plugged). Kind regards, Hannah.
Re: mutt 1.5.18 and set trash directive in .muttrc
On Thu, Jan 08, 2009 at 09:27:29PM +0800, David Schulz wrote: Hello all, i am using mutt 1.5.18 to handle my mail. I set it up via my muttrc file so that when i delete a mail, it goes to a Trash Folder. This is defined in muttrc like this set trash=$HOME/.mail/mlists.pg-sec.com/Trash/ Now id like to move my mail and setup to a OpenBSD 4.4 Machine, i installed Mutt 1.5.18 and everything works fine, except that mutt under OpenBSD doesn't seem to recognize the set trash directive in my .muttrc; instead upon starting mutt, mutt complains that: Error in /home/mlists/.mutt/muttrc, line 8: trash: unknown variable source: errors in /home/mlists/.mutt/muttrc This is strange, because set trash should be working without any patches or the like as far as i know. Can anyone help me to troubleshoot this? Thanks a lot, David !DSPAM:49660106805435209328925! as it appears, the trash directive is actually a patch that is not included in the mutt 1.5.18 package. sorry for the noise
Re: mutt 1.5.18 and set trash directive in .muttrc
Maybe it is because the Trash folder patch is not included by default on OpenBSD? You may compile your own version of Mutt with this patch applied if you wish. The patch is available from here: http://cedricduval.free.fr/mutt/patches/#trash 2009/1/8 David Schulz mailingli...@pg-sec.com: Hello all, i am using mutt 1.5.18 to handle my mail. I set it up via my muttrc file so that when i delete a mail, it goes to a Trash Folder. This is defined in .muttrc like this set trash=$HOME/.mail/mlists.pg-sec.com/Trash/ Now id like to move my mail and setup to a OpenBSD 4.4 Machine, i installed Mutt 1.5.18 and everything works fine, except that mutt under OpenBSD doesn't seem to recognize the set trash directive in my .muttrc; instead upon starting mutt, mutt complains that: Error in /home/mlists/.mutt/muttrc, line 8: trash: unknown variable source: errors in /home/mlists/.mutt/muttrc This is strange, because set trash should be working without any patches or the like as far as i know. Can anyone help me to troubleshoot this? Thanks a lot, David -- Andreas Kahari Somewhere in the general Cambridge area, UK
Authpf and more than 992 users
I'm running out of PTYs on my authpf firewall. Simply, more than 992 (max pty limit) users are trying to log in simultaneously. In theory I could disable (in authpf.c) checking whether or not session has been successfully allocated a pty, and force clients not to allocate a pty when connecting. But I suppose it was made for a reason -- could some kind soul please tell me what side-effects disabling this would have ? Is it at all possible to have more than 992 simultaneous authpf users ? -- Janusz Gumkowski http://www.am.torun.pl/~ja
Re: Size of SD devices supported?
On Thu, Jan 8, 2009 at 7:10 AM, Jonathan Gray j...@goblin.cx wrote:
On Thu, Jan 08, 2009 at 10:58:52AM +1100, Jonathan Gray wrote:
On Wed, Jan 07, 2009 at 02:49:50PM -0500, STeve Andre' wrote:
My new Thinkpad W500 has a SD slot, and stuffing a 1G card in
works just fine.
I borrowed a 16G SD card, and that gives a can't enable card
error.
I just found specs for the SD card, and wonder if the current
code works with cards beyond 4G? Or, do I have a defective 16G
card? (I currently have no way to test that). I haven't seen much
in the way of discussion about this.
This diff should let you use SDHC cards (most cards = 4GB).
Let me know how it goes.
Last one didn't have the change needed for block writes, try this:
Index: sdmmc.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving revision 1.16
diff -u -p -r1.16 sdmmc.c
--- sdmmc.c 2 Dec 2008 23:49:54 - 1.16
+++ sdmmc.c 8 Jan 2009 12:05:53 -
@@ -569,6 +569,32 @@ sdmmc_go_idle_state(struct sdmmc_softc *
}
/*
+ * Send the SEND_IF_COND command, to check operating condition
+ */
+int
+sdmmc_send_if_cond(struct sdmmc_softc *sc, uint32_t card_ocr)
+{
+ struct sdmmc_command cmd;
+ uint8_t pat = 0x23;
+ uint8_t res;
+
+ bzero(cmd, sizeof cmd);
+
+ cmd.c_opcode = SD_SEND_IF_COND;
+ cmd.c_arg = ((card_ocr SD_OCR_VOL_MASK) != 0) 8 | pat;
+ cmd.c_flags = SCF_CMD_BCR | SCF_RSP_R7;
+
+ if (sdmmc_mmc_command(sc, cmd) != 0)
+ return 1;
+
+ res = cmd.c_resp[0];
+ if (res != pat)
+ return 1;
+ else
+ return 0;
+}
+
+/*
* Retrieve (SD) or set (MMC) the relative card address (RCA).
*/
int
Index: sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.9
diff -u -p -r1.9 sdmmc_mem.c
--- sdmmc_mem.c 2 Dec 2008 23:49:54 - 1.9
+++ sdmmc_mem.c 8 Jan 2009 12:05:53 -
@@ -93,6 +93,9 @@ sdmmc_mem_enable(struct sdmmc_softc *sc)
/* Tell the card(s) to enter the idle state (again). */
sdmmc_go_idle_state(sc);
+ if (sdmmc_send_if_cond(sc, card_ocr) == 0)
+ host_ocr |= SD_OCR_SDHC_CAP;
+
/* Send the new OCR value until all cards are ready. */
if (sdmmc_mem_send_op_cond(sc, host_ocr, NULL) != 0) {
DPRINTF((%s: can't send memory OCR\n, SDMMCDEVNAME(sc)));
@@ -224,14 +227,23 @@ sdmmc_decode_csd(struct sdmmc_softc *sc,
* specification version 1.0 - 1.10. (SanDisk, 3.5.3)
*/
csd-csdver = SD_CSD_CSDVER(resp);
- if (csd-csdver != SD_CSD_CSDVER_1_0) {
+ switch (csd-csdver) {
+ case SD_CSD_CSDVER_2_0:
+ sc-sc_flags |= SMF_SDHC;
+ csd-capacity = SD_CSD_V2_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_V2_BL_LEN;
+ break;
+ case SD_CSD_CSDVER_1_0:
+ csd-capacity = SD_CSD_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
+ break;
+ default:
printf(%s: unknown SD CSD structure version
0x%x\n,
SDMMCDEVNAME(sc), csd-csdver);
return 1;
+ break;
}
- csd-capacity = SD_CSD_CAPACITY(resp);
- csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
} else {
csd-csdver = MMC_CSD_CSDVER(resp);
if (csd-csdver != MMC_CSD_CSDVER_1_0
@@ -403,7 +415,10 @@ sdmmc_mem_read_block(struct sdmmc_functi
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_READ_BLOCK_MULTIPLE : MMC_READ_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sc-sc_flags SMF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_CMD_READ | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
@@ -458,7 +473,10 @@ sdmmc_mem_write_block(struct sdmmc_funct
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_WRITE_BLOCK_MULTIPLE : MMC_WRITE_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sc-sc_flags SMF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
Index: sdmmcreg.h
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmcreg.h,v
retrieving revision 1.3
diff -u -p -r1.3 sdmmcreg.h
--- sdmmcreg.h 18
Re: Size of SD devices supported?
On Thu, Jan 08, 2009 at 09:32:47AM -0500, Dan Colish wrote:
The latest patch works great for me. I was not able to write disklabels with
the prior patch, probably due to the block write code missing. As soon as I
get the card up, I'll post some i/o benchmarks.
Well it's an SD card, don't expect miracles.
Here is a bonus revised revised patch that lets you use SD cards
after SDHC cards by storing the flag state in a better card specific
state structure.
I'd appreciate it if people testing this stuff could test on
a range of SDHC and normal cards and tell me what size cards/
which controllers they are testing against.
Thanks
Index: sdmmc.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving revision 1.16
diff -u -p -r1.16 sdmmc.c
--- sdmmc.c 2 Dec 2008 23:49:54 - 1.16
+++ sdmmc.c 8 Jan 2009 12:49:43 -
@@ -569,6 +569,32 @@ sdmmc_go_idle_state(struct sdmmc_softc *
}
/*
+ * Send the SEND_IF_COND command, to check operating condition
+ */
+int
+sdmmc_send_if_cond(struct sdmmc_softc *sc, uint32_t card_ocr)
+{
+ struct sdmmc_command cmd;
+ uint8_t pat = 0x23;
+ uint8_t res;
+
+ bzero(cmd, sizeof cmd);
+
+ cmd.c_opcode = SD_SEND_IF_COND;
+ cmd.c_arg = ((card_ocr SD_OCR_VOL_MASK) != 0) 8 | pat;
+ cmd.c_flags = SCF_CMD_BCR | SCF_RSP_R7;
+
+ if (sdmmc_mmc_command(sc, cmd) != 0)
+ return 1;
+
+ res = cmd.c_resp[0];
+ if (res != pat)
+ return 1;
+ else
+ return 0;
+}
+
+/*
* Retrieve (SD) or set (MMC) the relative card address (RCA).
*/
int
Index: sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.9
diff -u -p -r1.9 sdmmc_mem.c
--- sdmmc_mem.c 2 Dec 2008 23:49:54 - 1.9
+++ sdmmc_mem.c 8 Jan 2009 12:49:43 -
@@ -93,6 +93,9 @@ sdmmc_mem_enable(struct sdmmc_softc *sc)
/* Tell the card(s) to enter the idle state (again). */
sdmmc_go_idle_state(sc);
+ if (sdmmc_send_if_cond(sc, card_ocr) == 0)
+ host_ocr |= SD_OCR_SDHC_CAP;
+
/* Send the new OCR value until all cards are ready. */
if (sdmmc_mem_send_op_cond(sc, host_ocr, NULL) != 0) {
DPRINTF((%s: can't send memory OCR\n, SDMMCDEVNAME(sc)));
@@ -224,14 +227,23 @@ sdmmc_decode_csd(struct sdmmc_softc *sc,
* specification version 1.0 - 1.10. (SanDisk, 3.5.3)
*/
csd-csdver = SD_CSD_CSDVER(resp);
- if (csd-csdver != SD_CSD_CSDVER_1_0) {
+ switch (csd-csdver) {
+ case SD_CSD_CSDVER_2_0:
+ sf-flags |= SFF_SDHC;
+ csd-capacity = SD_CSD_V2_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_V2_BL_LEN;
+ break;
+ case SD_CSD_CSDVER_1_0:
+ csd-capacity = SD_CSD_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
+ break;
+ default:
printf(%s: unknown SD CSD structure version 0x%x\n,
SDMMCDEVNAME(sc), csd-csdver);
return 1;
+ break;
}
- csd-capacity = SD_CSD_CAPACITY(resp);
- csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
} else {
csd-csdver = MMC_CSD_CSDVER(resp);
if (csd-csdver != MMC_CSD_CSDVER_1_0
@@ -403,7 +415,10 @@ sdmmc_mem_read_block(struct sdmmc_functi
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_READ_BLOCK_MULTIPLE : MMC_READ_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sf-flags SFF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_CMD_READ | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
@@ -458,7 +473,10 @@ sdmmc_mem_write_block(struct sdmmc_funct
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_WRITE_BLOCK_MULTIPLE : MMC_WRITE_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sf-flags SFF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
Index: sdmmcreg.h
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmcreg.h,v
retrieving revision 1.3
diff -u -p -r1.3 sdmmcreg.h
--- sdmmcreg.h 18 Mar 2007 22:21:21 - 1.3
+++ sdmmcreg.h 8 Jan 2009 12:49:44 -
@@ -38,6 +38,7 @@
/* SD commands */ /* response type */
#define SD_SEND_RELATIVE_ADDR 3 /* R6 */
Re: Size of SD devices supported?
On Thu, Jan 8, 2009 at 9:51 AM, Jonathan Gray j...@goblin.cx wrote:
On Thu, Jan 08, 2009 at 09:32:47AM -0500, Dan Colish wrote:
The latest patch works great for me. I was not able to write disklabels
with
the prior patch, probably due to the block write code missing. As soon as
I
get the card up, I'll post some i/o benchmarks.
Well it's an SD card, don't expect miracles.
Here is a bonus revised revised patch that lets you use SD cards
after SDHC cards by storing the flag state in a better card specific
state structure.
I'd appreciate it if people testing this stuff could test on
a range of SDHC and normal cards and tell me what size cards/
which controllers they are testing against.
Thanks
Index: sdmmc.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving revision 1.16
diff -u -p -r1.16 sdmmc.c
--- sdmmc.c 2 Dec 2008 23:49:54 - 1.16
+++ sdmmc.c 8 Jan 2009 12:49:43 -
@@ -569,6 +569,32 @@ sdmmc_go_idle_state(struct sdmmc_softc *
}
/*
+ * Send the SEND_IF_COND command, to check operating condition
+ */
+int
+sdmmc_send_if_cond(struct sdmmc_softc *sc, uint32_t card_ocr)
+{
+ struct sdmmc_command cmd;
+ uint8_t pat = 0x23;
+ uint8_t res;
+
+ bzero(cmd, sizeof cmd);
+
+ cmd.c_opcode = SD_SEND_IF_COND;
+ cmd.c_arg = ((card_ocr SD_OCR_VOL_MASK) != 0) 8 | pat;
+ cmd.c_flags = SCF_CMD_BCR | SCF_RSP_R7;
+
+ if (sdmmc_mmc_command(sc, cmd) != 0)
+ return 1;
+
+ res = cmd.c_resp[0];
+ if (res != pat)
+ return 1;
+ else
+ return 0;
+}
+
+/*
* Retrieve (SD) or set (MMC) the relative card address (RCA).
*/
int
Index: sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.9
diff -u -p -r1.9 sdmmc_mem.c
--- sdmmc_mem.c 2 Dec 2008 23:49:54 - 1.9
+++ sdmmc_mem.c 8 Jan 2009 12:49:43 -
@@ -93,6 +93,9 @@ sdmmc_mem_enable(struct sdmmc_softc *sc)
/* Tell the card(s) to enter the idle state (again). */
sdmmc_go_idle_state(sc);
+ if (sdmmc_send_if_cond(sc, card_ocr) == 0)
+ host_ocr |= SD_OCR_SDHC_CAP;
+
/* Send the new OCR value until all cards are ready. */
if (sdmmc_mem_send_op_cond(sc, host_ocr, NULL) != 0) {
DPRINTF((%s: can't send memory OCR\n, SDMMCDEVNAME(sc)));
@@ -224,14 +227,23 @@ sdmmc_decode_csd(struct sdmmc_softc *sc,
* specification version 1.0 - 1.10. (SanDisk, 3.5.3)
*/
csd-csdver = SD_CSD_CSDVER(resp);
- if (csd-csdver != SD_CSD_CSDVER_1_0) {
+ switch (csd-csdver) {
+ case SD_CSD_CSDVER_2_0:
+ sf-flags |= SFF_SDHC;
+ csd-capacity = SD_CSD_V2_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_V2_BL_LEN;
+ break;
+ case SD_CSD_CSDVER_1_0:
+ csd-capacity = SD_CSD_CAPACITY(resp);
+ csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
+ break;
+ default:
printf(%s: unknown SD CSD structure version
0x%x\n,
SDMMCDEVNAME(sc), csd-csdver);
return 1;
+ break;
}
- csd-capacity = SD_CSD_CAPACITY(resp);
- csd-read_bl_len = SD_CSD_READ_BL_LEN(resp);
} else {
csd-csdver = MMC_CSD_CSDVER(resp);
if (csd-csdver != MMC_CSD_CSDVER_1_0
@@ -403,7 +415,10 @@ sdmmc_mem_read_block(struct sdmmc_functi
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_READ_BLOCK_MULTIPLE : MMC_READ_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sf-flags SFF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_CMD_READ | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
@@ -458,7 +473,10 @@ sdmmc_mem_write_block(struct sdmmc_funct
cmd.c_blklen = sf-csd.sector_size;
cmd.c_opcode = (datalen / cmd.c_blklen) 1 ?
MMC_WRITE_BLOCK_MULTIPLE : MMC_WRITE_BLOCK_SINGLE;
- cmd.c_arg = blkno 9;
+ if (sf-flags SFF_SDHC)
+ cmd.c_arg = blkno;
+ else
+ cmd.c_arg = blkno 9;
cmd.c_flags = SCF_CMD_ADTC | SCF_RSP_R1;
error = sdmmc_mmc_command(sc, cmd);
Index: sdmmcreg.h
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmcreg.h,v
retrieving revision 1.3
diff -u -p -r1.3 sdmmcreg.h
--- sdmmcreg.h 18 Mar 2007 22:21:21 - 1.3
+++ sdmmcreg.h 8 Jan 2009
(Fwd) Re: RESUBMIT: sysutils/apcupsd
missed the list when replying... --- Forwarded message follows --- On 7 Jan 2009 at 21:59, Toni Mueller wrote: Hi, On Sat, 03.01.2009 at 20:51:40 +0300, Kirill S. Bychkov ya...@linklevel.net wrote: This is a resubmit of apcupsd port. Any comments/oks? I have no comment on the port, just a question: What would be the advantage of using apcupsd in favour of nut? Better compatibility and smoother integration and management in heterogeneous (as far as OS's are concerned) environments. I find that some linux distros bundle an up-to-date apcupsd but nut is out of date or not available as a binary package. Things are even bleaker on the Windows side -- WinNUT is client only and older version at that. And although the two utilities have a very similar comm protocol, neither has made an effort to verify and ensure true compatibility. Kind regards, --Toni++ --- End of forwarded message ---
Re: spamd issues
Darrin Chandler wrote: On Tue, Jan 06, 2009 at 08:26:37PM -0500, Frank Bax wrote: I notice that one example line was removed from pf.conf: table spamd persist I guess I can delete that line from my file too? Er, you'll still need that unless something's happened that I totally missed. I'm thinking that line remembers something during reboot (but I'm not sure what that is). Does removing it forget GREY or WHITE or both? If you are running spamd on your mail server then it's a bit simpler: no rdr on $ext_if proto tcp from spamd-mywhite to any port smtp no rdr on $ext_if proto tcp from spamd-white to any port smtp rdr pass on $ext_if proto tcp from any to any port smtp \ - 127.0.0.1 port spamd Seems to be working just fine, thanks. GREY/WHITE issue is still there though.
Re: spamd issues
table spamd persist I guess I can delete that line from my file too? Er, you'll still need that unless something's happened that I totally missed. I'm thinking that line remembers something during reboot (but I'm not sure what that is). Does removing it forget GREY or WHITE or both? Tables and 'persist' are covered nicely in the man page. Persist keeps the table even if it's empty. It's nothing to do with reboots, and that it handled by spamd's database. If you are running spamd on your mail server then it's a bit simpler: no rdr on $ext_if proto tcp from spamd-mywhite to any port smtp no rdr on $ext_if proto tcp from spamd-white to any port smtp rdr pass on $ext_if proto tcp from any to any port smtp \ - 127.0.0.1 port spamd Seems to be working just fine, thanks. GREY/WHITE issue is still there though. I'm glad it's working. If it were really a problem then you'd have a bazillion GREY entries and/or no email would get through. It'll stop being an issue when you stop worrying about it ;) -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation [demime 1.01d removed an attachment of type application/pgp-signature]
Best supported arch/workstation
Hi, I am looking at purchasing a workstation to put OpenBSD on for programming development. What is the best supported arch overall? Or even better what is your most recommended workstation for running OpenBSD? Regards, Matt
Re: Best supported arch/workstation
From: Matt KP60 mattk...@gmail.com Hi, I am looking at purchasing a workstation to put OpenBSD on for programming development. What is the best supported arch overall? Or even better what is your most recommended workstation for running OpenBSD? i386, without any doubt whatsoever (imo). amd64 is almost as well supported. I've never personally had any issues with the sparc port (32 bit), but all those machines are old and slow. sgi could frankly do with a bit of work - but hey, it *is* the only commonly available full 64 bit OS available for the O2. PK
Re: Best supported arch/workstation
On Fri, Jan 09, 2009 at 06:48:57AM +1300, Matt KP60 wrote: Hi, I am looking at purchasing a workstation to put OpenBSD on for programming development. What is the best supported arch overall? Or even better what is your most recommended workstation for running OpenBSD? As always, the answer is it depends but i386 amd64 are both common and well supported. Depending on the kind of programming you're doing other options are also valid. At home I typically work on a Sun Ultra 5 (sparc64) and occasionally test on amd64 and i386. Mixing big/little endian, and 64/32 bit is really nice when developing. And if you can make performance acceptable on sparc64 then it'll scream on amd64/i386 I'd love to force the Firefox people develop and test on sparc64. ;-) -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Size of SD devices supported?
I've worked out my mount issues and I was able to run a bonnie++ test on the card: littleguy ~$ bonnie++ -d /opt/ -s 100 -r 10 -f -n 0 Writing intelligently...done Rewriting...done Reading intelligently...done start 'em...done...done...done... Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP littleguy 100M2144 1 1746 18950 1 170.5 0 Looks like its writing at 2Mb/sec and reading at almost 9mb/sec. The test size was 100Mb --dan
i have a proposal of trasaction of fund sum 12.6million usd I want to transfer
You are invited to i have a proposal of trasaction of fund sum 12.6million usd I want to transfer. By your host Denis Kabore: Date: Thursday January 8, 2009 Time: 7:00 pm - 8:00 pm (GMT +00:00) Guests: * mengskm...@yahoo.com.sg * mereanib...@yahoo.com * meri_d...@hotmail.com * merrianh...@yahoo.com.au * metaldownloa...@hotmail.com * metall...@hotmail.com * metehan0...@hotmail.com * meteorologis...@yahoo.com * meth8...@hotmail.com * mev...@tlbctx.org * me...@atate.mn.us * mfis...@hotmail.com * mf...@hotmail.com * mfoung...@hotmail.com * mgi...@hotmail.com * mgk11...@hotmail.com * mgohou...@hotmail.com * mgr40...@yahoo.com * mgrmu...@yahoo.com * mgrstore...@yahoo.com * mgsvenning...@hotmail.com * mha...@hotmail.com * mhuri...@yahoo.com.au * mhyal...@hotmail.com * miami-shopp...@hotmail.com * mianatmybl...@hotmail.com * mich.niel...@hotmail.com * michaelgood...@yahoo.co.uk * michaelhoo...@hotmail.com * michelle-p...@hotmail.com * michelledoz...@hotmail.com * mick_...@hotmail.com * mick...@hotmail.com * micoo...@hotmail.com * microagent...@yahoo.es * mi...@xtra.co.nz * mig...@nuclecu.unam.mx * miguel...@hotmail.com * miguel...@yahoo.com.mx * mikeo...@sbcglobal.net * mike...@yahoo.com * mikijonat...@yahoo.com.au * milad...@hotmail.com * millerbob1...@yahoo.com.ph * minlf1...@yahoo.com.cn * miplasticsurg...@yahoo.com * mirit...@hotmail.com * misc@openbsd.org * missatra...@yahoo.com * missdid...@hotmail.com * missra...@hotmail.com * mitti...@yahoo.co.uk * mixa_futbo...@hotmail.com * mizfl...@yahoo.com * mjharper...@hotmail.com * mjtremblayavoc...@yahoo.ca * mjwiltr...@msn.com * mjwsticki...@yahoo.ca * mkoc...@hotmail.com * mktnj.yo...@hotmail.com * mlbourni...@yahoo.co.nz * mlin...@hotmail.com * mlmarco2...@yahoo.co.uk * mlnorto...@hotmail.com * mlr...@yahoo.com * mmd...@yahoo.com * mmemo...@hotmail.com * mmont...@hotmail.com * mmori...@yahoo.com * modevicto...@hotmail.fr * modweeken...@hotmail.co.uk * mogg...@hotmail.com * mon_i...@yahoo.com * mongopete...@hotmail.com * monica__w...@hotmail.com * moniquegregoire...@hotmail.com * monstah.g...@hotmail.com * monster...@hotmail.com * monstro...@hotmail.com * moov...@hotmail.com invitation_add_to_your_yahoo_calendar: http://calendar.yahoo.com/?v=60ST=20090108T19%2BTITLE=i+have+a+proposal+of+trasaction+of+fund+sum+12.6million+usd+I+want+to+transferDUR=0100VIEW=dDESC=i+have+a+proposal+of+trasaction+of+fund+sum+12.6million+usd+I+want+to+transferTYPE=10 Copyright ) 2009 All Rights Reserved www.yahoo.com Privacy Policy: http://privacy.yahoo.com/privacy/us Terms of Service: http://docs.yahoo.com/info/terms/
Re: Heirloom troff on OpenBSD 4.4 / libc / i386
On Wed, 7 Jan 2009 18:29:54 -0800
Philip Guenther guent...@gmail.com wrote:
I contacted the author (G. Ritter) who suggested to compile the program
with the debug flag (-g), and to subsequently run it in gdb.
I did that, but not being a developer, the output did not tell me
anything useful.
...
This GDB was configured as i386-unknown-openbsd4.4...(no debugging
symbols found)
You may have built it with -g to include debugging symbols, but the
binary was apparently stripped along the way. If the -s option is
passed when doing the final linking, then remove it. If the 'strip'
command is being run, comment it out or disable it. Then try running
it under gdb again.
I disabled the strip command. Now, I get the output below from gdb.
I think, I'll best report it to the author of the software, as it does
not make an awful lot of sense to me.
Thanks for your support.
$ gdb troff
GNU gdb 6.3
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-unknown-openbsd4.4...
(gdb) run
Starting program: /opt/ucb/troff
Program received signal SIGSEGV, Segmentation fault.
0x1c006b06 in addlig (f=1, from=0xcfbf6620, to=0) at t6.c:1340
1340if (codetab[f][fitab[f][LIG_FF-32]] 32)
(gdb) bt full
#0 0x1c006b06 in addlig (f=1, from=0xcfbf6620, to=0) at t6.c:1340
i = 1
j = 2
lp = (struct lgtab *) 0x0
#1 0x1c006dbd in setlig (f=1, j=6) at t6.c:1413
from = {102, 105, 0, 0}
to = -8377880580443839399
#2 0x1c008774 in loadafm (nf=1, rq=82, file=0x7cd053ed R, supply=0x0,
required=1, spec=SPEC_PUNCT) at t6.c:2084
st = {st_dev = 16, st_ino = 8548, st_mode = 33188, st_nlink = 1, st_uid
= 1000, st_gid = 0, st_rdev = 36424, st_lspare0 = -685213332, st_atimespec =
{tv_sec = 1231455322,
tv_nsec = 586991087}, st_mtimespec = {tv_sec = 1231455322, tv_nsec =
586991087}, st_ctimespec = {tv_sec = 1231455322, tv_nsec = 606989709}, st_size
= 31354, st_blocks = 64,
st_blksize = 16384, st_flags = 0, st_gen = 0, st_lspare1 = -685641728,
__st_birthtimespec = {tv_sec = -685641696, tv_nsec = 5}, st_qspare =
{233159961, 42353225560}}
fd = 1
path = 0x8849f400 /opt/ucblib/doctools/font/devps/R.afm
contents = 0x861f5ba4
a = (struct afmtab *) 0x84aa9a00
i = 1
have = 0
np = (struct namecache *) 0x6459
#3 0x1c001b2b in ptinit () at t10.c:237
i = 1
nw = 0
filebase = 0x7cd0540d
p = 0x7cd0540d
descp = 0x0
#4 0x1c00aed4 in init2 () at ../n1.c:447
i = 25689
j = 0
#5 0x1c00aa27 in main (argc=0, argv=0xcfbf6830) at ../n1.c:309
p = 0xcfbf6988 /opt/ucb/troff
j = 25689
oargv = (char **) 0xcfbf6830
Re: Best supported arch/workstation
I've never personally had any issues with the sparc port (32 bit), but all those machines are old and slow. Hush, my little inetra. I'm sure he wasn't really talking about you. You are very good at what you do. And you're right: it's not your fault I haven't found a replacement for your dead nvram battery. Once I remind you about who you are, and what you should be doing, you never forget anything until the next unplanned power event. And besides it's not how much processor power or memory you have or how big your hard drive that makes you attractive to me. It's the little things we have shared together over time: dns, dhcp, sendmail, apache. I could go on and on. Whew...that was a close one.
Belkin F5D5005 has switched from sk(4) to re(4) RTL8169
Hello all, Just a heads up if anyone specifically tries to get sk(4) by sourcing Belkin F5D5005 cards. I just purchased a pack of 10, since I had others which were sk(4), but these new cards are all RTL8169 based. The box shows Ver.2001 Shane
E220 as 3G Internet Access
Dear all i have E220 from Huawei for mobile internet connection . Now i want using E220 as internet sharing from my obsd 4.4 box. i have found good link obsd 4.4 and E220 http://www.jensolsson.se/?p=123 when i try connect get error like this bellow : Jan 9 13:54:15 bsd pppd[28000]: pppd 2.3.5 started by root, uid 0 Jan 9 13:54:20 bsd pppd[28000]: Connect: ppp0 -- /dev/ttyU0 Jan 9 13:54:23 bsd pppd[28000]: Could not determine remote IP address Jan 9 13:54:23 bsd pppd[28000]: Connection terminated. Jan 9 13:54:25 bsd pppd: Exit. here my ppp conf : # cat /etc/ppp/qiandra /dev/ttyU0 crtscts defaultroute noauth connect '/usr/sbin/chat -v -f /etc/ppp/qiandra.chat' # chat # cat /etc/ppp/qiandra.chat ABORT NO CARRIER ABORT NO DIALTONE ABORT ERROR ABORT NO ANSWER ABORT BUSY ABORT Username/Password Incorrect TIMEOUT 15 ATZ OK ATE1 OK ATQ0V1E1S0=0C1D2+FCLASS=0 OK 'AT+CGDCONT=1,IP,apnisp' OK ATDT*99***1# TIMEOUT 30 CONNECT \d\c # options # cat /etc/ppp/options modem defaultroute netmask 255.255.255.0 ipcp-accept-local ipcp-accept-remote noipdefault lock auth usehostname # basic my isp using dhcp for ip address and i must set static dns for tunning. so how to solved my problem with E220 and OBSD 4.4 do i missing something ? -- sonjaya http://idsale.blogspot.com http://videopingpong.blogspot.com -- learning trik play table tenis form expert
