Subject: Re: Why shoud we cause panic in scsi_da.c?
Date: Tue, 14 Jul 2015 15:49:29 -0400
> On Mon, Jul 13, 2015 at 18:29:36 +0300, Alexander Motin wrote:
>> Hi.
>>
>> On 13.07.2015 11:51, Kohji Okuno wrote:
>> >> On 07/13/15 10:11, Kohji Okuno wrote:
>&
Hi,
From: Alexander Motin
Date: Mon, 13 Jul 2015 18:29:36 +0300
> Hi.
>
> On 13.07.2015 11:51, Kohji Okuno wrote:
>>> On 07/13/15 10:11, Kohji Okuno wrote:
>>>> Could you comment on my quesion?
>>>>
>>>>> I found panic() in scsi_da.c.
Hi HPS,
Thank you for your comment.
I will wait for the commnet.
Kohji Okuno
> On 07/13/15 10:11, Kohji Okuno wrote:
>> Hi,
>>
>> Could you comment on my quesion?
>>
>> Best regards,
>> Kohji Okuno
>>
>>> Hi,
>>>
>>>
Hi,
Could you comment on my quesion?
Best regards,
Kohji Okuno
> Hi,
>
> I found panic() in scsi_da.c. Please find the following.
> I think we should return with error without panic().
> What do you think about this?
>
> scsi_da.c:
> 3018 } else
0)
3020panic("REQ_CMP with QFRZN");
Best regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "fr
Hi Konstantin,
I tested your patch. It was no problem.
Thank you for your kind correspondence.
Regards,
Kohji Okuno
> On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>>
>> > At the end of the mail is commit candidate. I did not even com
Hi Konstantin,
Thank you very much for your detailed explanatin.
I understood the policy of vmem.
Many thanks,
Kohji Okuno
> On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wr
Hi,
> On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
>> Hi Konstantin,
>>
>> Thank you for your prompt response.
>> I will test and report from next monday.
>>
>> >> In addtion, I have one question.
>> >> In current and 10
ct. This is why I only did the stable/9 patch.
Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable?
Could you please explain me?
Regards,
Kohji Okuno
> On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>>
>> > At the e
.
(2) should use pmap_resident_count_inc() in amd64.
I will test, later.
In addtion, I have one question.
In current and 10-stable, is vm_map_delete() called by kva_free()?
If vm_map_delete() is called, this fix is needed in current and
10-stable, I think.
Regards,
Kohji Okuno
> On Sat, O
ut, if
kernel_pmap.pm_stats.resident_count is zero, then any managed pages
(for example pipe_map, exec_map, or etc.) are not able to change
unmanaged status, because pmap_remove() returns without calling
pmap_remove_pte().
In this result, I encounterd the panic. Could you refer the following?
Regards,
Kohji
Hi,
At least in i386 && 9-stable, when we call pmap_mapdev() and
pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
incorrectly.
pmap_mapdev_attr()->pmap_kenter_attr():
In this path, kernel_pmap.pm_stats.resident_count is not increlmented.
pmap_unmapdev()->kmem_free(kernel_map)->v
> Hi,
>
> Please verify:
> http://svnweb.freebsd.org/changeset/base/271953
>
> Thank you!
>
> --HPS
Hi, HPS,
I confirmed your commit. It was no problem.
Many thanks,
Kohji Okuno.
___
freebsd-current@freeb
> On 09/22/14 08:31, Kohji Okuno wrote:
>> Hi HPS,
>>
>> Could you refer to the following document (4.6.6 Configure Endpoint:P.99)?
>> This document shows:
>>
>> If the Drop Context flag is `1' and the Add Context flag is `1', the xHC
>>
ources and Bandwidth requested for
the endpoint.
Regards,
Kohji Okuno.
> On 09/22/14 06:58, Kohji Okuno wrote:
>> Hi,
>>
>> I encountered a issue for USB mic.
>>
>> In fist time, my host controller (xHCI) sends single IN-tokens every
>> 8-SOFs. This is expec
t do you think about this change?
Best regards,
Kohji Okuno
static usb_error_t
xhci_configure_mask(struct usb_device *udev, uint32_t mask, uint8_t drop)
{
struct xhci_softc *sc = XHCI_BUS2SC(udev->bus);
struct usb_page_search buf_inp;
struct xhci_input_dev_ctx
struct usb_page {
64 #if USB_HAVE_BUSDMA
65 bus_size_t physaddr;
66 void *buffer; /* non Kernel Virtual Address */
67 #endif
68 };
Regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing
at do you think about this?
Regards,
Kohji Okuno
From: takehara.mikih...@jp.panasonic.com
Subject: uninitialized journal data written in SU+J ?
Date: Tue, 22 Apr 2014 16:21:43 +0900
> Hello,
>
>
> I'm testing UFS with SU+J. But it seems sometimes broken journal data h
From: Konstantin Belousov
Date: Thu, 3 Apr 2014 16:48:14 +0300
> On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote:
>> > The done_ev_add case is indeed missed in my patch, thank you for noting.
>> > The case of EV_ADD does not need the KN_SCAN workaround, IMO, s
kn->kn_status &= ~KN_HASKQLOCK;
> - KQ_UNLOCK(kq);
> - }
> + kn->kn_status &= ~KN_INFLUX;
> + if (error)
> + KNOTE_ACTIVATE(kn, 1);
> +
From: Konstantin Belousov
Date: Wed, 2 Apr 2014 15:07:45 +0300
> On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
>> From: John-Mark Gurney
>> Date: Tue, 1 Apr 2014 23:15:51 -0700
>> > Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
>&
From: John-Mark Gurney
Date: Tue, 1 Apr 2014 23:15:51 -0700
> Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
>> I think, kevent() has a bug.
>> I tested sample programs by attached sources.
>> This sample tests about EVFILT_SIGNAL.
>>
>&g
t on calling
kn->kn_fop->f_event() in kqueue_scan(), I think.
What do you think about this issue?
Best regards,
Kohji Okuno
#include
#include
#include
#include
int
main()
{
sleep(1);
exit(0);
}
#include
#include
#include
#include
#include
#include
#i
> Kohji Okuno wrote this message on Fri, Feb 28, 2014 at 11:13 +0900:
>> I have a question about kevent.
>>
>> How should the userland judge knote which is cleared from knlist by
>> knlist_clear() or knlist_delete()?
>
> It looks like I need to read the code
Hi,
I have a question about kevent.
How should the userland judge knote which is cleared from knlist by
knlist_clear() or knlist_delete()?
Best regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman
unlock.
But, the process that is notified will start over kqueue_scan() after
knlist_destroy(). And, in KN_LIST_LOCK(kn), the context will call NULL
function (kn->knlist->kn_lock).
Regards,
Kohji Okuno
> On 02/27/14 11:39, Kohji Okuno wrote:
>> Hi HPS and John-Mark,
>>
>>
Hi John-Mark,
Thank you for your comment.
I added knote_clear() and knote_destroy() in kbd_detach(). I attached
patch, again. But, maybe this patch can not resolve all cases you
pointed.
Regards,
Kohji Okuno
> Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:24 +0900:
>> I
Hi HPS and John-Mark,
After I changed as the following, the kernel panic does not happen.
What do you think about this change?
+ knlist_clear(&f->selinfo.si_note, 0);
knlist_destroy(&f->selinfo.si_note);
Regards,
Kohji Okuno
> We should wait for empty
Hi HPS and John-Mark,
We should wait for empty of knlist before knlist_destroy().
When I tried 262551, the kernel panic at KN_LIST_LOCK(kn) in
kern_event.c.
Regards,
Kohji Okuno
> On 02/27/14 10:00, Hans Petter Selasky wrote:
>> Hi Kohji,
>>
>> Can you verify th
From: Hans Petter Selasky
> On 02/27/14 08:13, Kohji Okuno wrote:
>> Hi John-Mark,
>>
>> Thank you for you comment.
>>
>> From: John-Mark Gurney
>>> Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:26 +0900:
>>>> I tried add kqueue I
Hi John-Mark,
Thank you for you comment.
From: John-Mark Gurney
> Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:26 +0900:
>> I tried add kqueue I/F to usb_dev.c. I attached my patch.
>> What do you think about my patch?
>
> A few comments...
>
> 1) You
Hi John-Mark,
I tested the attached sample source with USB mouse.
Thanks,
Kohji Okuno
From: John-Mark Gurney
> Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:26 +0900:
>> I tried add kqueue I/F to usb_dev.c. I attached my patch.
>> What do you think about my patch?
&
Hi,
I tried to add kqueue I/F to kbd.c. I attached patch.
What do you think about my patch?
Best regards,
Kohji Okuno
diff --git a/sys/dev/kbd/kbd.c b/sys/dev/kbd/kbd.c
index 8036762..df000ab 100644
--- a/sys/dev/kbd/kbd.c
+++ b/sys/dev/kbd/kbd.c
@@ -59,6 +59,9 @@ typedef struct genkbd_softc
Hi,
I tried add kqueue I/F to kbd.c. I attached my patch.
What do you think about my patch?
Best regards,
Kohji Okuno
diff --git a/sys/dev/kbd/kbd.c b/sys/dev/kbd/kbd.c
index 8036762..df000ab 100644
--- a/sys/dev/kbd/kbd.c
+++ b/sys/dev/kbd/kbd.c
@@ -59,6 +59,9 @@ typedef struct genkbd_softc
Hi,
I tried add kqueue I/F to usb_dev.c. I attached my patch.
What do you think about my patch?
Best regards,
Kohji Okuno
diff --git a/sys/dev/usb/usb_dev.c b/sys/dev/usb/usb_dev.c
index f086a3c..4334be7 100644
--- a/sys/dev/usb/usb_dev.c
+++ b/sys/dev/usb/usb_dev.c
@@ -120,6 +120,9 @@ static
462
>
> Thank you!
>
> --HPS
Hi HPS,
Thank you for informing your commit.
I tried your latest patch. It is OK in my environment.
Many thanks,
Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
From: Hans Petter Selasky
Date: Thu, 12 Dec 2013 09:37:29 +0100
> On 12/12/13 08:40, Kohji Okuno wrote:
>> From: Hans Petter Selasky
>>
>> Hi HPS,
>>
>> The endpoint type is BULK, and the direction is OUT.
>>
>> I checked by using a USB analyzer. Wh
From: Hans Petter Selasky
Date: Thu, 12 Dec 2013 08:15:02 +0100
> On 12/12/13 01:59, Kohji Okuno wrote:
>> From: Hans Petter Selasky
>> Date: Wed, 11 Dec 2013 15:04:42 +0100
>>> On 12/11/13 14:06, Kohji Okuno wrote:
>>>>
>>>> Hi HPS,
>>>
From: Hans Petter Selasky
Date: Wed, 11 Dec 2013 15:04:42 +0100
> On 12/11/13 14:06, Kohji Okuno wrote:
>>
>> Hi HPS,
>>
>> All link trbs which are not the end need CHAIN bit, I think.
>> But, this is errata in xHCI ver 0.95. So, linux has quirk for chain
&g
From: Hans Petter Selasky
Date: Wed, 11 Dec 2013 13:50:50 +0100
> On 12/11/13 13:44, Hans Petter Selasky wrote:
>> On 12/11/13 12:12, Kohji Okuno wrote:
>>>> On 12/11/13 11:12, Kohji Okuno wrote:
>>>>> Hi,
>>>>>
>>>>> I think the x
From: Hans Petter Selasky
Date: Wed, 11 Dec 2013 13:44:37 +0100
> On 12/11/13 12:12, Kohji Okuno wrote:
>>> On 12/11/13 11:12, Kohji Okuno wrote:
>>>> Hi,
>>>>
>>>> I think the xHCI host controller driver has a spec violation.
>>>>
>
> On 12/11/13 11:12, Kohji Okuno wrote:
>> Hi,
>>
>> I think the xHCI host controller driver has a spec violation.
>>
>> Could you refer to
>> ``Table 126: Offset 0Ch – Link TRB Field Definitions''
>> in xHCI_Specification_for_USB.pdf(Rev
_TRB_3_TYPE_SET(XHCI_TRB_TYPE_LINK) |
1895XHCI_TRB_3_CYCLE_BIT | XHCI_TRB_3_IOC_BIT;
1896
1897td->td_trb[x].dwTrb3 = htole32(dword);
1898
1899td->alt_next = td_alt_next;
--
Best regards,
Kohji Okuno
___
}
65
66 /* Prepare for the next round. */
67 oldval = curval;
68 }
69
70 return 0;
71 }
Many thanks,
Kohji Okuno
> On Tue, Jun 18, 2013 at 06:15:56PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> This is newer document.
>>
>> http://pubs.
break;
> 118 default:
> 119 return (EINVAL);
> 120 }
> 121
> 122 if (oldtype) {
> 123 *oldtype = oldval ? PTHREAD_CANCEL_ASYNCHRONOUS :
> 124 PTHREAD_CANCEL_DEFERRED;
> 125 }
> 126 return (0);
&g
if (oldtype) {
123 *oldtype = oldval ? PTHREAD_CANCEL_ASYNCHRONOUS :
124 PTHREAD_CANCEL_DEFERRED;
125 }
126 return (0);
127 }
Regards,
Kohji Okuno
___
freebsd-curr
Hi Konstantin,
Thank you for your comment.
I don't have any solution for this issue.
And when a device is removed suddenly, there are other problems, I think.
> On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> When I removed a device (ex. /d
mented dev->si_threadcount, but can't acquire
topology_lock.
On the other hand, g_event is waiting to set dev->si_threadcount to 0
with topology_lock.
Regards,
Kohji Okuno
<<< Thread A >>>
...
devfs_open()
{
...
dsw = dev_refthread(dev, &ref); <= inc
ase check this?
Thanks,
Kohji Okuno
<>
215 ENTRY(cpu_switch)
216 stmfd sp!, {r4-r7, lr}
217 mov r6, r2 /* Save the mutex */
218
219 .Lswitch_resume:
220 /* rem: r0 = old lwp */
221 /* rem: interrupts are disabled */
222
ether packet.
I think that `eh = mtod(m, struct ether_header *);' is needed after
line 580.
Thanks,
Kohji Okuno
sys/net/if_ethersubr.c:
448 static void
449 ether_input_internal(struct ifnet *ifp, struct mbuf *m)
450 {
451 struct ether_header *eh;
484 e
Hi,
I'm sorry. I forgot to attach a file.
Regards,
Kohji Okuno
> Hi David,
>
> From: David Chisnall
>
>> If you have a test case, I can commit it to the libc++ test suite.
>>
>> David
>
> I attached my test source.
> This test program shoud o
069, 0069
But, when I use original toupper.c, this proguram output as below.
towupper_l
0049, 0049
0131, 0131
0130, 0069
0069, 0049
towlower_l
0049, 0069
0131, 0131
0130, 0069
0069, 0069
Regards,
Kohji Okuno
>
> On 10 May 2012, at 21:42, Kohji Okuno wrote:
>
>> Hi Eric,
>&g
t suite checks only popular characters.
__mapupper_ext is used in case of special characters.
For example, Turkish 'i' (0x0131) should convert 'I' (0x49).
Regards,
Kohji Okuno
> Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
>
>> On 2012-05-10 11:02, Kohji Oku
s->__mapupper_ext;
_RuneEntry *base, *re;
if (c < 0 || c == EOF)
Best regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &q
Hi HPS,
Do you have better idea?
From: Kohji Okuno
Date: Tue, 24 Jan 2012 09:53:29 +0900 (JST)
> Hi HPS,
>
>> On Monday 23 January 2012 09:12:46 Kohji Okuno wrote:
>>> Hi HPS,
>>>
>>> I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap.
>&
Hi HPS,
> On Monday 23 January 2012 09:12:46 Kohji Okuno wrote:
>> Hi HPS,
>>
>> I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap.
>> And, in xhci.c you set UPS_PORT_POWER as folows.
>>
>> When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET
S_PP) {
/*
* The USB 3.0 RH is using the
* USB 2.0's power bit
*/
i |= UPS_PORT_POWER;
}
Regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing
Hi HPS,
From: Hans Petter Selasky
Subject: Re: Can you use a USB3.0 hub?
Date: Thu, 12 Jan 2012 22:23:22 +0100
> On Thursday 12 January 2012 07:15:17 Kohji Okuno wrote:
>> Hi,
>>
>> Can you use a USB3.0 hub?
>>
>> I tried a USB3.0 hub (BUFFALO BSH4A04U3BK).
-interface-card/
The kernel could not recognize USB3.0 HDD that connected to this hub
as the following log. But, the kernel could reconize USB2.0 HDD that
connected to this hub.
Regards,
Kohji Okuno
-- log
xhci0: mem 0xf7ffe000-0xf7ff irq 28 at d
evice 0.0 on pci1
Hi Selasky,
I think XHCI_PS_PP is wrong.
- #define XHCI_PS_PP 0x0100 /* RW - port power */
+ #define XHCI_PS_PP 0x0200 /* RW - port power */
Could you check it?
Best regards,
Kohji Okuno
___
freebsd
Hi Kostic and Jaakko,
> On Fri, Aug 05, 2011 at 06:45:22PM +0300, Jaakko Heinonen wrote:
>> On 2011-08-03, Kostik Belousov wrote:
>> > On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
>> > > > devfs_populate(), and the context holds only "d
Hello Kostik,
>> > On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
>> >> But, now I'm using 8.1-RELEASE. May I have advice about 8.X ?
>> > Do you mean a patch for the stable/8 ? I believe it is enough to
>> > apply rev. 211628 to
Hello Kostik,
> On Thu, Aug 04, 2011 at 11:41:39AM +0900, Kohji Okuno wrote:
>> Hello Kostik,
>>
>> From: Kostik Belousov
>> Subject: Re: Bug: devfs is sure to have the bug.
>> Date: Wed, 3 Aug 2011 16:50:44 +0300
>> > I think the problem you descri
Hello Kostik,
From: Kostik Belousov
Subject: Re: Bug: devfs is sure to have the bug.
Date: Wed, 3 Aug 2011 16:50:44 +0300
Message-ID: <20110803135044.gm17...@deviant.kiev.zoral.com.ua>
> On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
>> Hello,
>>
>>
p_generation != devfs_generation)
goto retry;
dm->dm_generation = tmp_generation;
#else /* Original */
if (dm->dm_generation == devfs_generation)
return;
while (devfs_populate_loop(dm, 0))
continue;
dm->dm_generation = devfs_generation;
#endif
}
Thanks,
Kohji Okuno (okuno.ko...@jp.panasonic.com)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ct cdev_priv *cdp;
mtx_assert(&devmtx, MA_OWNED);
cdp = cdev2priv(dev);
cdp->cdp_flags &= ~CDP_ACTIVE;
devfs_generation++;
}
Thanks.
--
Kohji Okuno (okuno.ko...@jp.panasonic.com)
___
freebsd-current@freebsd.or
Hello,
> From: Kostik Belousov
> Date: Tue, 12 Jul 2011 17:57:53 +0300
>> On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
>>> 2011/7/12 Kostik Belousov :
>>> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
>>> >> Hello
Hello,
From: Kostik Belousov
Date: Tue, 12 Jul 2011 17:57:53 +0300
> On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote:
>> 2011/7/12 Kostik Belousov :
>> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
>> >> Hello,
>> >>
>&
l 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote:
>> Hello,
>>
>> I think that devfs has a problem.
>> I encountered the problem that open("/dev/AAA") returned ENOENT.
>> Of course, /dev/AAA exists.
>>
>> ENOENT was created by the point(***) in dev
(error == 0)
vput(vp);
return (ENOENT);
}
else if (error) {
+#if 1
+ if (error == ENOENT)
+ goto retry;
+#endif
sx_xunlock(&am
Thank you for your comments.
In my usage, it works good by the patch appended to this mail.
> On May 24, 2010, at 2:49 AM, pluknet wrote:
>
>> On 24 May 2010 08:49, Kohji Okuno wrote:
>>> Hi all,
>>>
>>> I want to compile 32bit binary on amd64, but I me
7 44 24 08 03 00 00movl $0x3,0x8(%esp)
80484f8: 00
80484f9: c7 44 24 04 00 10 00movl $0x1000,0x4(%esp)
8048500: 00
8048501: c7 04 24 00 00 00 00movl $0x0,(%esp)
8048508: e8 3b fe ff ff call 8048348
How should
72 matches
Mail list logo
