Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncvncr53c500var.h src/sys/dev/stg tmc18c30var.h
From: Warner Losh [EMAIL PROTECTED] Date: Fri, 31 May 2002 17:39:55 -0600 In message [EMAIL PROTECTED] Alfred Perlstein writes: : I'm really fine with either. Let's wait till tomorrow for anyone to : speak up, if no one does please feel free to commit whichever one you : feel more comfortable with. Aarrgh. I just committed my workaround, which basically adds 0 to each of the tests. I did this as it is the smallest change I could think of to do the deed since these drivers are maintained outside of the tree. Thank you Waner-san and Takahashi(nyan)-san. I did not notice. May be it should be #ifdef NetBSD or something. // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ThinkPad X22 PC-Card slot problem
Sorry for late reply. I didn't have time to test it. From: M. Warner Losh [EMAIL PROTECTED] Date: Thu, 07 Feb 2002 10:04:35 -0700 (MST) Yes. This is the ISA problem. The checks are there to make sure we don't assign addresses that aren't decoded by the bridge. However, the bridge does decode ISA addresses. I need to check into which ISA stuff a little better before making a fix. Revision ChangesPath 1.7 +30 -14src/sys/dev/pci/pci_pci.c This fixed half of the problem, thank you. However, X22's PCICs (yes two PCICs) request to use 0x5000-0x5fff and 0x5000-0x5fff where the bridge does not know. So I still need PCI_ALLOW_UNSUPPORTED_IO_RANGE. pcib1: PCI-PCI bridge at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode0x3000-0x3fff pcib1: memory decode 0xc010-0xc01f pcib1: prefetched decode 0xe000-0xe7ff pci1: physical bus=1 map[10]: type 3, range 32, base e000, size 27, enabled map[14]: type 4, range 32, base 3000, size 8, enabled map[18]: type 1, range 32, base c010, size 16, enabled found- vendor=0x1002, dev=0x4c59, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 : pcic0: Ricoh RL5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 3.0 on pci2 pcib2: device pcic0 requested unsupported memory range 0x5000-0x5fff ( decoding 0xc020-0xcfff, 0xe800-0xf00f) pcib2: device pcic0 requested decoded memory range 0x5000-0x5fff // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ThinkPad X22 PC-Card slot problem
Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I recently installed -current to ThinkPad X22. Though it seems that X22's PC-Card slots work fine with -stable, in -current when probing PCICs I got following message, pcic0: Ricoh RL5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 3.0 on pci2 pcib2: device pcic0 requested unsupported memory range 0x5000-0x5fff (decoding 0xc020-0xcfff, 0xe800-0xf00f) pcib2: device pcic0 requested decoded memory range 0x5000-0x5fff after this, pcic returns error but some how it is attached and when I install a PC-Card, the machine freezes. The address range above (0x5000-0x5fff) is same one that I see with -stable. When PCI_ALLOW_UNSUPPORTED_IO_RANGE is defined in sys/dev/pci/pci_pci.c, pcic does not return error, the machine does not freeze, but when a PC-Card is inserted I get the message, pccard: card inserted, slot 0 pcic0: reset 1 int is 10 stat is 5f pcic0: reset 2 int is 70 stat is 5f pcic0: reset 3 int is 70 stat is 7f pcic0: Event mask 0x9 pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f : and the card does not attached. The complete dmesg with boot -v is attached. Any ideas ? // Noriaki Mitsunaga // Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Application/Octet-Stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmesg.X22-current.gz H4sICCZVXzwCA2RtZXNnLlgyMi1jdXJyZW50AOw8/W/buJI/13/FoHfvkOzZDkl92rcpnuOk ra9Nk4vTfQssHgJZomK92JJWktu4f/3NkJKsOLbjZFssHrBFqlDiDOeDM8MZisowSZdZdDst 4MA/BN7riY5gTMD1VMLbTMqT8SlcZsm/pF90W8M1YKfXxqvL1NVQV1tdXXVVvT2urkJdFUzP bL2i4a/krYyLHJIQCrz9HEdfZJZHxZKeDL1ZFCZZHHldGMxmoMjmkMlcZl9k0G1VzFld1hl+ vro6+3QN/8F5H64XyLmcAFiAt4bd5z343/E1kFgtwH9ZkhR/L1LGuzLrevO8K+PbbpJ7d15n 0fX87r/S/tEiz47yzD/Kl/lRZLj2kZ/M02gmj96dfTq7Gg1bl5mcJV4gA5CzEO5kFssZvD6a 4NhH+q789Rq8Ati9zyxLMsa6a5jzJFjM5Bqm56dR9y55gDoxUf+olEnmFVF8C/4s8e8O8kPo drtwPR7qB31weo5hMm704P23NkSusMyqi/OewR0HO1rDjx9uPo/PbkbUfzMcfBydXA2uRxef IE4KyFPpR2GELHZgkRO1QIbeYlZAmMnfFzL2l63raC79ZBEXMoPXisxrWHVrWq5o0kIm96CU zALwKzmTGOaymCbBQ3I40gNiSma0MVORu/zch0u0rGgxh9FodNRow68yiY+GciYzHPoA8bqG 1Tl//w1s1+74My/PAfEP0U4u0OKiGI7h9TsZL6JYjpA2ziaMAnzI7u0JBxgXMk2J62PgiPNW esUCTfSY3RuuEfbC8Oe3l5/bv5yftU/P2pfjszZy3j4fX7UvB2ft8+FZe/ir2x6fXbbPr6/w 4Tt6OGgPzy9+QYhrwjDs9vn5r+23vyLSeHz2ppVJb4ZKmSfZEpCsyQSzDcNmcGD0hG2yDzBZ FjI/bF1Ol3nkr4D96SImg+m32D0aIuP4H7WubnoyDMM22KbDbVcPAAfcciH1bmksArJcq8Lg Tmg7CsPo2cIUPdOskHq2g6ZXonlfvKimfwyGawnhuox4dWz0x5rXSZTkhujDW5zhAE5GF2ND wBg9PfIlnEYZRh8aYirRb7LKK1joGC6rcc/iQlFh92HgSKRBENQ6BAw1X6gH4KOM1VylfkR4 aCjDkaIHUqGroRHLYf+NYrqylcapBtSsXcaXGjzwCq/JiGQr0IqTkNTc97jBKw54twn2BWlC OPNuaSBzYrYuMA5mevw8uo21MUFIlPuteDGb9eFn+oXuSJppwze04/IGLcOLg2SOICQKRmrI k0VGHTgB+LSchv+C0dHFm1blFBjbgYwP8kWaJlmBevAmMxmQhm6SVMYH/LD/CqOUBA5eEGSg oA7QIvzQPYQoRxW4ypq42UDySiyu3cFl+h8hVu1DBe6Ht/5UYnh6peXAWfpNOeIxswnqn/Db NMiOqYG0SEESDqLg2LAcy2Wufdj6rOLGf16OrqAg3nGNMdV0Rqi8eooCOWGtOL1npAqvmEKa Jb7M8yR7AxRmEhp6knhZUEKNcEHhNkQUckLPly2KyoQ9OjmnZeT6ssNP8fcjdOocDC9HHYaO 0YeffvoJzrIsyfpwrmIZyHvpL1RwC9E/ZNCGwdnNp4vrm7NfR+PrPx2/lDNNvqIxThZFgYCo +imaFwKDh0qFMLrHZqjjHanyNvPmc5oHmvRZ92G8Jm4eBGycvJ5lWhSuvwe3NwVSy2huhNmZ RAWoe5p7o6spYYh/oy0X3Zoxt6N+TWjqlLh6GD9d0CC4ArxZ6ym+UQfN8Rwj6rcklusQsyhQ uAk536xi/mMUwPhrVPjTdXitWEIZz6RM4UTdr0NRnCKY90ledChWTbIouJW1LOiDHbqGKzxE odmrov9kgZ7UejX30t84+2cfimUqAfMwjBa32MC8bOLlEoLSKdsYeb5JEJjBVZFAxZ/Om1cY roIkU85MaR66K61z6IY4GLpugHeYYb1SBHGYWVLQ73AR+8RA5dMdxjpEBp2aWCEkvJuHargn adnbafFNtMx1WnxFS+lE1DoxH+lErZJurROw9tSJMF3R4JM/5FP0HjHqd5ixVSmIjjEIs4xj D/O57PdjzvdlXbyEdXMP1vl+rLOa9clzWTdfwrqzB+viuaz7NetPkDfdFXlzjbzBnmudT8nq b5fV2OgKfJeFPQwPmyeF8bCeFGM1KRrXfALXCM0KV6zjuk/RdbbT9Z+i62yl+7QR2jVdc38j 9PaYmJX/cJoYwtlthKXrC8val3f3JQ5k7MG70XQg6/m+/5SZcX8VcdGj1EIXRPkzjI27fj2C vT7CUyqw9lCBVavA3OVXL1aBMP+oCsRqKQfnuSqw91CBXavAee4KoBOUn1U2s8jrjEfnOqoy 47r7QcKDyVxZIGARRTg0TAUNkGO2GQceFjg4JuWUZZGnOxeTJAsiLKhk2d3oxHIIR/apwin/ YabBKEu5N7DGXQGWBVQDlioLrsJMRzXD8AFCmslQYuqHmXKJxO5lmWchgnTCGoGvZWz86YxN rmVszjNDssEeGNmWkMwf4VYil7jc3hFeEFJUhmX6Vq9hWEwbFt+aKRq7M8UNSZGqWGhHCQRU 9WwOpwxOOZwKODUA/EWWUdV9ykqtPzBDNXNVB7pLOvOWbfjl3aBpfgzN7yDGsjuj/UrsKDya 4sPWYqoNW20UgStcxoeDo+HgHA5Gw/fGIXwen4Cv64MZYuJtZ7CqSlxlFNzlIQkEnDdoil7D 5hf55AVkEFsxWKITEM1FToUVbUsspgt6rkf9/B61QvukgE/boDfGekdMzR+BsyO6tPWOAK+Q BWiVY8EzxZsMHeaLrshz2utU84NmQnzwZ0pw0lCU0IoyNiuKNxX1AjKloniJvlFR/I8oij9L UQIlUFQObmUss8hf57uhGFMrxtqsGLFSjB734JP8qiU4VUCjoEyj9b4Kyr8H8VJdogTfqC6i 1Rj5RVoTe2uNvFjsXEEMtraEiM1LiGh0PlpC3FXnpiXE1EHerVYEsX0JEfUSEq5WBI2wcQlx 6yUkZKxGEGtLiFhfQh6HcuvhEsLFrlDOKaPUoZyZzULcc3UoF1WOsKn6cNZDudhZ3z4vlO8h KP+BgvLnCjr5YYKSMfGGoHxfQS1LPF6c1wV9UDuzDn9yx8LfR9CdIj7Oe8LnGK2waxEN19lQ
Re: ThinkPad X22 PC-Card slot problem
From: M. Warner Losh [EMAIL PROTECTED]
Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST)
Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell
Inspiron 8000. I can boot with apm enabled. There are issues with
routing interrupts accross PCI PCI bridges at the moment when the
slots on the other side of the bridge are in the PIR table.
It turned out that this was not a intterupt routing problem. By
disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved
the problem (below is the patch). pci_pci.c claims that both the
memory adderss for pcic and the PC-Cards are not supported but I could
use the addresses.
// Noriaki Mitsunga //
Index: pci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v
retrieving revision 1.6
diff -u -r1.6 pci_pci.c
--- pci_pci.c 15 Jan 2002 06:46:59 - 1.6
+++ pci_pci.c 7 Feb 2002 09:55:44 -
@@ -282,15 +282,18 @@
*/
switch (type) {
case SYS_RES_IOPORT:
+#if 0
if (start sc-iobase)
start = sc-iobase;
if (end sc-iolimit start end)
end = sc-iolimit;
+#endif
if ((start sc-iobase) || (end sc-iolimit)) {
device_printf(dev, device %s%d requested unsupported I/O range
0x%lx-0x%lx
(decoding 0x%x-0x%x)\n,
device_get_name(child), device_get_unit(child), start,
end,
sc-iobase, sc-iolimit);
+#define PCI_ALLOW_UNSUPPORTED_IO_RANGE
#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
return(NULL);
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ThinkPad X22 PC-Card slot problem
I recently installed -current to ThinkPad X22. Though it seems that X22's PC-Card slots work fine with -stable, in -current when probing PCICs I got following message, pcic0: Ricoh RL5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 3.0 on pci2 pcib2: device pcic0 requested unsupported memory range 0x5000-0x5fff (decoding 0xc020-0xcfff, 0xe800-0xf00f) pcib2: device pcic0 requested decoded memory range 0x5000-0x5fff after this, pcic returns error but some how it is attached and when I install a PC-Card, the machine freezes. The address range above (0x5000-0x5fff) is same one that I see with -stable. When PCI_ALLOW_UNSUPPORTED_IO_RANGE is defined in sys/dev/pci/pci_pci.c, pcic does not return error, the machine does not freeze, but when a PC-Card is inserted I get the message, pccard: card inserted, slot 0 pcic0: reset 1 int is 10 stat is 5f pcic0: reset 2 int is 70 stat is 5f pcic0: reset 3 int is 70 stat is 7f pcic0: Event mask 0x9 pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f : and the card does not attached. The complete dmesg with boot -v is attached. Any ideas ? // Noriaki Mitsunaga // dmesg.X22-current.gz Description: Binary data
Re: ThinkPad X22 PC-Card slot problem
From: Takanori Watanabe [EMAIL PROTECTED] Date: Wed, 06 Feb 2002 23:16:21 +0900 I recently installed -current to ThinkPad X22. Though it seems that X22's PC-Card slots work fine with -stable, in -current when probing PCICs I got following message, : How about disabling ACPI? If this works, it is because ACPI PCI interrupt routing problem. No, disabling ACPI does not change the situation. // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: od driver for -CURRENT
From: Bruce Evans [EMAIL PROTECTED] Date: Sun, 11 Feb 2001 07:35:51 +1100 (EST) On Sat, 10 Feb 2001, Justin T. Gibbs wrote: Are there any reason device drivers do not check if thier devices are writable or not when they are opened ? I think returning an error value, like `od', is the easiest way to avoid this problem. It is not necessarily sufficient since the media may be changed after open on certain types of devices that don't have a media lock. Some devices will only tell you that they are write protected on the first write, etc. For the devices where we can tell, we should make the check in open, but not rely on that catching all cases where a driver will return EACCESS. Also, writing to a write protected sector is a special case of an i/o error, so it will be handled by non-broken general i/o error handling. Also^2, write protection might be for individual sectors and might change while the device is open, just like most i/o errors. We actually have this for most disks -- FreeBSD has write protection of label sectors in software, and it can be turned on and off while the device is open. Though both of them cannot be handled, I think it's worth checking if the entire device is write-protected or not at open(). Especially when the implementation is not so difficult. Why you have to try writing to a write-protected medium ? // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: Bruce Evans [EMAIL PROTECTED] Date: Sat, 10 Feb 2001 06:24:20 +1100 (EST) On Fri, 9 Feb 2001 [EMAIL PROTECTED] wrote: From: "Kenneth D. Merry" [EMAIL PROTECTED] Hmm, can you demonstrate the problem? The write-protect check in the od driver is one of the things that the da driver doesn't have. I figured it wouldn't really be necessary, since any attempted writes would be returned with errors. The problem is you cannot unmount after -rw mount with a write-protected medium. This is essentially the same bug that causes problems for writing to write protected media or unwriteable blocks using the block device. Are there any reason device drivers do not check if thier devices are writable or not when they are opened ? I think returning an error value, like `od', is the easiest way to avoid this problem. I first saw this problem for a floppy driver that I wrote in 1984. It retried endlessly. Users did not like this :-). I was told not to write-protect floppies when using UNIX :-( // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: "Kenneth D. Merry" [EMAIL PROTECTED] Subject: Re: od driver for -CURRENT By the way, in Japanese users mailing list, some said that `da' does not check whether a medium is writerable or not (write protected). If you mount a write protected medium with -rw, it will lead bad condition when you do umount. Hmm, can you demonstrate the problem? The write-protect check in the od driver is one of the things that the da driver doesn't have. I figured it wouldn't really be necessary, since any attempted writes would be returned with errors. The problem is you cannot unmount after -rw mount with a write-protected medium. Below has been done also in 4.2-RELEASE with GENERIC kernel, 1. Insert a write protected medium, 2. mount /dev/da0s1c /mnt, cel# mount /dev/da0s1c /mnt 3. umount /mnt cel# umount /mnt umount: unmount of /mnt failed: Input/output error cel# umount /mnt umount: unmount of /mnt failed: Input/output error Umount does not success and `Write protected' messages continue to appear 4. reboot (umount fails) In /var/log/mesages, Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): Write protected Hope this helps. // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: Bernd Walter [EMAIL PROTECTED] Date: Wed, 7 Feb 2001 17:11:57 +0100 On Tue, Feb 06, 2001 at 11:21:12PM +0900, [EMAIL PROTECTED] wrote: Today I tried with 4.2-RELEASE (sorry not -current) and, 1. Boot up the 4.2-RELEASE with GENERIC kernel. 2. Connect MO drive with PC Card SCSI(ncv). 3. Insert PC Card without medium in the MO drive. 4. The pccardd automatically run camcontrol rescan. 5. Message says that da0 is 0MB capacity. 6. Run fdisk da0 7. got panic with divided by zero. Probably divided by zero is caused at line 737 or 748 in the scsi_low_action() in cam/scsi/scsi_low.c because of ccg-block_size or secs_per_cylinder is zero. I tried with same drive and another SCSI card (ahc0) in 4.2-RELEASE. No problem were found. I watched the diffs between da.c and od.c. It seems like some fault in scsi_low.c. Hmm, my fault Sorry for claiming `da'. By the way, in Japanese users mailing list, some said that `da' does not check whether a medium is writerable or not (write protected). If you mount a write protected medium with -rw, it will lead bad condition when you do umount. I never used fdisk on a removeable disk as I only needed them for FreeBSD. : It looks like fdisk triggers the bug. I used fdisk just to check if there is a slice or not. Fdisk did not make problem. // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: Bernd Walter [EMAIL PROTECTED] Date: Tue, 6 Feb 2001 13:30:30 +0100 Though I have not tried `da' lately, if you don't insert a medium in the drive at the time of CAM rescan bus, `da' tries to get the geometry by XPT_CALC_GEOMETRY then panics with divided by zero in most SCSI drivers. With `od' it says just the medium is 0MB and does not cause panic. Probably `od' knows the medium is not in the drive (watching UNIT READY or something?). Sounds very much like a bug which should be fixed than worked around. Especialy when even the workaround doesn't run! I should have written that I didn't dare to do above in 4-stable and 5-current with `da' driver. I tried with 3.x without `od'. Today I tried with 4.2-RELEASE (sorry not -current) and, 1. Boot up the 4.2-RELEASE with GENERIC kernel. 2. Connect MO drive with PC Card SCSI(ncv). 3. Insert PC Card without medium in the MO drive. 4. The pccardd automatically run camcontrol rescan. 5. Message says that da0 is 0MB capacity. 6. Run fdisk da0 7. got panic with divided by zero. Probably divided by zero is caused at line 737 or 748 in the scsi_low_action() in cam/scsi/scsi_low.c because of ccg-block_size or secs_per_cylinder is zero. If I insert a 128MB medium in the drive at 3, no panic occurs. I asume your drive firmware doesn't send a propper 'NOT READY'. I don't think so. I tried two drives and many people claimed that `da' caused the same problem with MOs and Zips in Japanese mailing lists at the era of 3.x . That's the one reason many people in Japan eager to `od'. Is it safe to change the size (geometry) of media with `da', eg. at first no medium (0MB), then 128MB, 230MB, 640MB (sector size is 2048bytes) and so on ? I didn't dare to do this medium change with `da'. Because I thought `da' did not read the geometry when I changed media. Can you provide us with the exact message and a stack trace from the system? And don't forget the exact drive inquiry string and version. I will try with -current later (may be in one week). // Noriaki Mitsuanga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: "Kenneth D. Merry" [EMAIL PROTECTED] Date: Mon, 5 Feb 2001 17:00:41 -0700 I think we already have the most important functionality from the od(4) driver in the da and cd drivers. If there are any features that are in the od(4) driver that should be in the da(4) or cd(4) drivers, but aren't, please speak up. Though I have not tried `da' lately, if you don't insert a medium in the drive at the time of CAM rescan bus, `da' tries to get the geometry by XPT_CALC_GEOMETRY then panics with divided by zero in most SCSI drivers. With `od' it says just the medium is 0MB and does not cause panic. Probably `od' knows the medium is not in the drive (watching UNIT READY or something?). Is it safe to change the size (geometry) of media with `da', eg. at first no medium (0MB), then 128MB, 230MB, 640MB (sector size is 2048bytes) and so on ? // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ncv, nsp, stg SCSI drivers
Sorry, the files colud not fetch. I think you can now fetch them. // Noriaki Mitsunaga From: [EMAIL PROTECTED] Date: Sat, 30 Sep 2000 15:20:07 +0900 From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Wed, 27 Sep 2000 15:25:42 +0200 Use a normal timeout ? I changed to use timeout() and now they do not change clock.c. Updated files can be obtained from, http://home.jp.freebsd.org/~non/scsi_low-2930.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-2930.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-2930.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. Or you can obtain the diff from, http://home.jp.freebsd.org/~non/scsi_low-2926-2930.diff.gz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ncv, nsp, stg SCSI drivers
From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Wed, 27 Sep 2000 15:25:42 +0200 Use a normal timeout ? I changed to use timeout() and now they do not change clock.c. Updated files can be obtained from, http://home.jp.freebsd.org/~non/scsi_low-2930.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-2930.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-2930.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. Or you can obtain the diff from, http://home.jp.freebsd.org/~non/scsi_low-2926-2930.diff.gz // Noriaki Mitsunaga To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[CFR] ncv, nsp, stg SCSI drivers
Call for review, ncv, nsp, and stg SCSI drivers which are ported from NetBSD/pc98. I would like to merge to current and do MFC. ncv: NCR 53C500 based SCSI PC-CARDs nsp: Ninja SCSI-3 based SCSI PC-CARDs stg: TMC 18C30 based SCSI PC-Cards and ISA cards. They are tested and working on PAO3 and there are entries (totally 19) in /etc/pccard.conf, though commented out. I would like to have review especially on the changes in i386/isa/clock.c for counting delay loop numbers, and converts of SCSI layer from NetBSD one to CAM in cam/scsi/scsi_low.[ch] . They can be obtained from http://home.jp.freebsd.org/~non/scsi_low-2926.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-2926.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-2926.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. // Noriaki Mitsunaga To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ncv, nsp, stg SCSI drivers
From: Poul-Henning Kamp [EMAIL PROTECTED]
Date: Wed, 27 Sep 2000 15:01:13 +0200
I would like to have review especially on the changes in
i386/isa/clock.c for counting delay loop numbers,
Could you explain the functionality you need here ? We already
have a DELAY() macro/function in the kernel...
There are codes like;
int tout = sc-sc_wc;
;
while (slp-sl_scp.scp_datalen 0 tout -- 0)
{
;
}
To calculate the tout we use;
sc-sc_wc = delaycount * 2000; /* 2 sec */
And we initialize the delaycount in clock.c.
// Noriaki Mitsunaga
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ncv, nsp, stg SCSI drivers
From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Wed, 27 Sep 2000 15:13:27 +0200 And we initialize the delaycount in clock.c. This is called "busy polling" and there must be a better way to do it. Do you have any suggestions ? Has this code been profiled to examine typical actual delay lengths ? I don't know. I obtained these codes from NetBSD/pc98 and I did not change here. // Noriaki Mitsunaga To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
